這兩年Android方向的課程設(shè)計和畢業(yè)設(shè)計短視頻相關(guān)的題目是真不少。前段時間拿到一個《基于Android的短視頻推薦系統(tǒng)》的完整工程帶全套源碼和文檔從用戶登錄到視頻播放再到個性化推薦都有算是把“App開發(fā)”和“推薦算法落地”兩件事串起來了。我花了幾天時間把工程跑通、把代碼過了一遍又把推薦部分的算法單獨拎出來測了幾組數(shù)據(jù)今天把整個分析和實操過程整理出來。無論你是要做課程設(shè)計、畢業(yè)設(shè)計還是單純想看看“推薦系統(tǒng)在Android端到底怎么玩”這篇都應(yīng)該能幫你省下不少踩坑的時間。先說結(jié)論這套系統(tǒng)不是那種只有一個登錄頁的“假項目”它包含了視頻信息流、播放器集成、點贊評論、基于協(xié)同過濾的推薦模塊以及一整套數(shù)據(jù)庫和網(wǎng)絡(luò)層封裝。你拿到的源碼可以直接編譯成APK裝到手機上后端邏輯和推薦計算也都能在本地跑通。對于想快速交作業(yè)、或者想在此基礎(chǔ)上做二次開發(fā)的人來說是一個性價比很高的起點。接下我會從項目定位、技術(shù)選型、核心模塊拆解、源碼運行、問題排查這幾個角度來展開過程中會穿插推薦算法的計算邏輯和一些我實際調(diào)參時的經(jīng)驗。內(nèi)容偏實操代碼和配置都直接給建議你對照源碼一起看。1. 項目定位與技術(shù)全貌這個短視頻推薦系統(tǒng)到底做了什么1.1 項目解決的三個核心問題但凡涉及到“推薦”兩個字系統(tǒng)要解決的本質(zhì)問題就離不開三點內(nèi)容多、用戶時間少、匹配效率低。放到短視頻場景下表現(xiàn)就更明顯了。你刷到一個視頻要么是點贊收藏要么是劃走每次交互都是一次反饋推薦系統(tǒng)要做的就是通過連續(xù)反饋不斷調(diào)整下一次出什么內(nèi)容。這套Android短視頻推薦系統(tǒng)把這三個問題都做了覆蓋。內(nèi)容多靠視頻管理模塊來承載支持上傳、分類、列表展示用戶時間少靠沉浸式豎屏信息流來解決上滑下滑切換視頻交互路徑很短匹配效率低則靠推薦模塊來實現(xiàn)系統(tǒng)會記錄用戶的看視頻行為離線計算出一份“你可能喜歡的內(nèi)容列表”再推送到App端。值得說明的是這里的“推薦”不是簡單的按發(fā)布時間倒序排列而是有一個完整的用戶行為采集和偏好計算閉環(huán)。源碼里可以清楚看到用戶看過哪些視頻、點贊過哪些視頻、劃走了哪些視頻都會被記錄下來作為推薦計算的輸入。1.2 系統(tǒng)整體架構(gòu)與數(shù)據(jù)流設(shè)計整個工程從架構(gòu)上看是標(biāo)準(zhǔn)的客戶端-服務(wù)端模式但服務(wù)端邏輯并不是獨立部署的Web項目而是通過Android工程內(nèi)部的數(shù)據(jù)庫操作和推薦引擎來完成。如果你只是想跑課設(shè)演示一臺電腦一個模擬器就夠了不需要額外搭服務(wù)器。數(shù)據(jù)流的走向是這樣的用戶打開App后先進入推薦信息流頁面客戶端向推薦模塊請求“獲取推薦視頻列表”推薦模塊讀取本地數(shù)據(jù)庫中已經(jīng)計算好的推薦結(jié)果表按推薦分值排序返回給界面層。用戶每產(chǎn)生一次點擊、點贊、評論或者滑動行為界面層都會把行為寫入交互記錄表同時更新用戶對視頻的偏好標(biāo)簽。等到下一次進入推薦頁或者點擊刷新按鈕時推薦引擎會根據(jù)最新的行為記錄重新計算候選視頻的得分然后更新推薦列表。這樣設(shè)計的優(yōu)勢很明顯所有邏輯都在一個工程里沒有跨端聯(lián)調(diào)成本數(shù)據(jù)都在本地數(shù)據(jù)庫演示和管理都方便。缺點也現(xiàn)實就是當(dāng)數(shù)據(jù)量變大之后單次全量計算所有用戶的推薦列表會變慢。源碼里其實已經(jīng)對這種問題做了處理使用了“離線計算在線讀取”的方式大部分計算是在用戶行為變化后的一個短周期內(nèi)完成的不會在滑動視頻時卡頁面。1.3 與其他短視頻平臺的差距在哪里既然提到“短視頻推薦系統(tǒng)”你難免會拿它和抖音、快手這類產(chǎn)品對比。從推薦流程的基本框架來說核心環(huán)節(jié)是相通的用戶畫像、物品特征、交互行為、推薦列表生成。區(qū)別主要在于工程復(fù)雜度和算法精細度。大廠的做法是海量實時特征、深度學(xué)習(xí)模型、線上AB實驗一套完整的機器學(xué)習(xí)平臺支撐這些在課程設(shè)計層面完全不需要照搬。這套源碼的價值在于它用最樸實的方式把推薦的“骨架”做出來了。你拿起工程看能理解用戶在信息流里的每一次操作是如何變成數(shù)據(jù)、數(shù)據(jù)又是如何變成推薦結(jié)果的這就達到了學(xué)習(xí)目的。后續(xù)你要往里面加深度學(xué)習(xí)模型也好加多路召回也好都是在這個骨架上的局部替換不會推翻重來。2. 關(guān)鍵技術(shù)與工具選型為什么這么選2.1 技術(shù)棧清單及組件定位技術(shù)選型這件事對于課程設(shè)計來說第一原則是“別給自己挖坑”。用得太偏門出了問題沒人能幫你查資料用得太舊找依賴都費勁用得太新自己都不熟更別提改代碼。這套源碼的技術(shù)棧整體是比較穩(wěn)的技術(shù)項選型定位說明開發(fā)語言Java部分?jǐn)?shù)據(jù)腳本為Python做課設(shè)和畢設(shè)選Java最保險資料多、示例多不會因為語言本身卡住網(wǎng)絡(luò)層OkHttp Retrofit Gson最通用的Android網(wǎng)絡(luò)棧組合無論視頻列表還是上傳接口都用它圖片加載Glide加載封面圖和頭像處理網(wǎng)絡(luò)圖片緩存避免列表滑動時重復(fù)加載視頻播放ExoPlayer相比MediaPlayerExoPlayer對網(wǎng)絡(luò)流的支持更好還能播放HLS、Dash等格式數(shù)據(jù)庫SQLite 自封裝DBHelper輕量、無需額外配置數(shù)據(jù)庫文件放在應(yīng)用私有目錄演示方便推薦算法基于物品的協(xié)同過濾 熱度補充Item-Based CF 是推薦入門最經(jīng)典算法解釋性強實現(xiàn)難度適中開發(fā)環(huán)境Android Studio Gradle JDK 8常規(guī)配比兼容性和穩(wěn)定度都經(jīng)過驗證這套選型組合最大的特點是“同學(xué)之間能互相幫上忙”。你遇到任何依賴沖突或編譯問題網(wǎng)上搜報錯基本都有現(xiàn)成答案不像用了某些冷門框架資料都找不到幾篇。2.2 推薦算法方案對比與選型邏輯推薦系統(tǒng)里最常被提到的三種基礎(chǔ)算法基于內(nèi)容的推薦、基于用戶的協(xié)同過濾、基于物品的協(xié)同過濾。做項目選型時要考慮如何在一兩個月內(nèi)既要能寫出來、又要能講清楚還要在答辯時有亮點。基于內(nèi)容的推薦本質(zhì)是“找和你喜歡的內(nèi)容相似的視頻”。實現(xiàn)要依賴內(nèi)容標(biāo)簽體系建設(shè)比如給每個視頻打上分類、題材、風(fēng)格標(biāo)簽。優(yōu)勢是冷啟動相對容易新視頻只要有標(biāo)簽就能推薦缺點是標(biāo)簽質(zhì)量直接影響推薦效果而且用戶興趣泛化能力弱?；谟脩舻膮f(xié)同過濾核心是“和你口味相似的人喜歡什么你也可能喜歡”。實現(xiàn)要計算用戶之間的相似度。問題在于在課設(shè)這種小規(guī)模數(shù)據(jù)量下用戶基數(shù)不夠相似用戶的計算結(jié)果會很稀疏推薦列表容易趨同?；谖锲返膮f(xié)同過濾是“看你喜歡過的視頻找出和這些視頻相似的其他視頻推給你”。相似度的計算依據(jù)不是標(biāo)簽而是“多少人同時喜歡了這兩個視頻”這個邏輯非常樸素但效果在短視頻場景下反而穩(wěn)定也很容易和評委解釋。這套源碼采用的是基于物品的協(xié)同過濾然后加了一道熱度兜底。我自己實際驗證下來這個選擇在課設(shè)和畢設(shè)場景里確實是性價比最高的方案。而且后續(xù)如果你想寫“算法改進”也有足夠的擴展空間比如把UserCF和ItemCF做成加權(quán)混合這就可以作為論文里的創(chuàng)新點。2.3 開發(fā)環(huán)境與工程配置要點拿到源碼后第一步是核對環(huán)境。工程要求的最低SDK版本、編譯SDK版本、Gradle版本這幾個參數(shù)建議先看一眼build.gradle再決定要不要升級或降級。目前Android Studio新版默認(rèn)用的JDK版本和Gradle版本都偏高如果源碼是用老版本建的會出現(xiàn)無法同步、AGP版本不兼容、依賴下載超時等問題。我的做法是先保持源碼原有的Gradle版本不變讓Android Studio自動下載對應(yīng)版本如果下載太慢就更換國內(nèi)鏡像源。這里有一個很實用的經(jīng)驗Gradle發(fā)行包的分發(fā)地址如果默認(rèn)是services.gradle.org下載經(jīng)常能磨上十分鐘去項目的gradle/wrapper/gradle-wrapper.properties文件里我把distributionUrl換成騰訊鏡像地址速度直接起飛。另外一個重點是AndroidManifest.xml里的權(quán)限配置。短視頻應(yīng)用至少需要網(wǎng)絡(luò)權(quán)限、存儲權(quán)限部分機型寫外部存儲或讀取媒體文件用。真機運行時Android 6.0以上需要在代碼里動態(tài)申請權(quán)限源碼里已經(jīng)有對應(yīng)的封裝如果你自己改過版本號別把這塊漏掉否則會出現(xiàn)“點擊視頻一直黑屏但沒崩潰”的詭異現(xiàn)象。3. 功能模塊拆解與核心實現(xiàn)3.1 用戶模塊注冊登錄與會話保持用戶模塊做的是最基礎(chǔ)的三件事賬號注冊、賬號登錄、登錄狀態(tài)保持。沒有用戶系統(tǒng)后面的“個性化推薦”就無從談起因為推薦算法必須知道“是哪個用戶在產(chǎn)生行為”。注冊頁和登錄頁的UI是獨立Activity登錄成功后會把用戶ID寫入SharedPreferences后續(xù)所有和用戶相關(guān)的請求都會攜帶這個ID。數(shù)據(jù)庫中的用戶表字段包括用戶ID、用戶名、密碼、頭像路徑、注冊時間。這里提一個我在源碼里注意到的細節(jié)密碼保存用的是明文。做課設(shè)可以理解但你如果想做得更規(guī)范至少應(yīng)該加一道MD5加鹽處理這一條在答辯時主動提出來會是一個加分項。會話保持的邏輯不復(fù)雜App啟動時會檢查本地存儲的登錄狀態(tài)如果已登錄則直接進入主頁否則跳轉(zhuǎn)到登錄頁。沒有做Token過期處理和自動刷新對于單機演示場景問題不大。3.2 視頻信息流與播放器集成信息流頁面是App的門面也是用戶停留時間最長的頁面。實現(xiàn)上用的是RecyclerView加上垂直分頁的滑動效果也就是滑動一個item的距離就停住形成整屏切換的沉浸式體驗。視頻列表的item從上到下依次是封面圖、作者頭像、作者名、視頻標(biāo)題、點贊按鈕、評論按鈕、收藏按鈕。列表數(shù)據(jù)來源于數(shù)據(jù)庫的video表每加載一頁拉取固定數(shù)量的視頻記錄。推薦頁則多了一步查詢的是推薦結(jié)果表按推薦分值排好序再展示。視頻播放的核心是ExoPlayer。每個item對應(yīng)一個SimpleExoPlayer實例監(jiān)聽滑動的狀態(tài)來執(zhí)行播放和暫停。這里有一個很關(guān)鍵的細節(jié)因為滑動切換很快player的創(chuàng)建和釋放如果過于頻繁會非?？?。源碼里的做法是復(fù)用了幾個player實例在item可見時切換播放源而不是每個item創(chuàng)建新播放器。這個優(yōu)化思路在很多商業(yè)App里也在用課設(shè)里你能寫出來面試時也能拿出來聊。播放器的狀態(tài)監(jiān)聽還包括視頻緩沖中顯示loading、緩沖完成自動播放、播放結(jié)束回到第一幀。這些看起來是小細節(jié)但沒有它們整個App的體驗就會非常生硬。3.3 點贊、評論、收藏與行為記錄互動模塊一方面是社交功能的體現(xiàn)另一方面是為推薦算法提供最重要的信號來源。打開視頻詳情或信息流可以點擊點贊、跳去評論、點收藏每種行為都會寫入用戶行為記錄表。行為記錄表的設(shè)計我單獨拎出來說一下字段包括記錄ID、用戶ID、視頻ID、行為類型點贊、評論、收藏、瀏覽、劃走、行為時間。這個表是整個推薦系統(tǒng)的“原料庫”后面計算視頻相似度、生成推薦列表全都要從這些記錄里統(tǒng)計。從評分角度來說不同的行為信號權(quán)重應(yīng)該不同。源碼里給了一套簡單的打分映射點贊是5分收藏是8分評論是10分瀏覽超過5秒是1分劃走是0分。這個設(shè)計很實用你完全可以在自己的項目里調(diào)整這些分值來改變推薦風(fēng)格。比如你想讓“評論”這種高成本行為的權(quán)重更突出就把評論分值調(diào)高到15推薦結(jié)果就會傾向于推那些容易引發(fā)討論的內(nèi)容。3.4 數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計數(shù)據(jù)庫這塊信息量比較大我把核心表的字段整理成了一張表你對著看源碼會更清楚表名關(guān)鍵字段作用userid, username, password, avatar, create_time用戶登錄和畫像基礎(chǔ)videoid, user_id, title, cover_url, video_url, category, like_count, comment_count, create_time視頻內(nèi)容數(shù)據(jù)和統(tǒng)計信息user_video_behaviorid, user_id, video_id, behavior_type, behavior_score, create_time用戶行為記錄推薦算法輸入源video_similarityvideo_id_a, video_id_b, similarity_score物品相似度離線計算結(jié)果預(yù)先算好recommend_resultuser_id, video_id, recommend_score, create_time每個用戶的最終推薦列表其中video_similarity和recommend_result是推薦系統(tǒng)專門加的“算法落地”表。所有相似度計算的結(jié)果都提前算好存起來用戶請求推薦時只需要查表排序不用當(dāng)場跑計算。這個設(shè)計思路在真實工業(yè)界也是通用的即“離線計算、在線服務(wù)”。3.5 推薦模塊的核心算法實現(xiàn)推薦模塊是整個項目含金量最高的部分。我把它拆成三步來講保證你不光能跑通還能跟任何人把原理講明白。第一步從行為記錄構(gòu)建評分矩陣。假設(shè)有三個用戶A、B、C四個視頻1、2、3、4矩陣?yán)锏闹荡碛脩魧σ曨l的偏好分。用戶沒看過的地方填0。這個矩陣不必追求滿分值的合理性關(guān)鍵是能反映出不同視頻被同一批人喜歡時表現(xiàn)出的一種關(guān)聯(lián)結(jié)構(gòu)。第二步計算物品之間的相似度。這里用的是余弦相似度。兩個視頻的相似度取決于有多少用戶同時喜歡或同時反感它們。公式的本質(zhì)是把兩個視頻的評分向量放在高維空間里求余弦夾角夾角越小說明方向越一致也就是被同一類人喜歡。計算時把無數(shù)個用戶的行為匯聚成一個向量再用向量夾角表示相似度用戶量越大這個相似度就越穩(wěn)定。第三步生成推薦列表。拿到用戶看過的視頻找到和它們最相似的Top-N視頻再排除掉用戶已經(jīng)看過的內(nèi)容對剩下的按推薦分值排序分值高的排前面。下面我從源碼里摘了一段簡化后的核心邏輯用Java寫的關(guān)鍵結(jié)構(gòu)public ListVideo recommendForUser(int userId) { // 1. 讀取該用戶行為記錄取出所有交互過的視頻ID ListInteger watchedVideoIds getUserWatchedVideos(userId); // 2. 目標(biāo)候選視頻得分Map MapInteger, Double scoreMap new HashMap(); for (int watchedId : watchedVideoIds) { // 查詢與 watchedId 相似度最高的前N個視頻 ListSimilarVideo similarVideos getTopSimilarVideos(watchedId, 10); for (SimilarVideo sv : similarVideos) { if (watchedVideoIds.contains(sv.getVideoId())) { continue; // 已經(jīng)看過的跳過不要重復(fù)推薦 } double sim sv.getSimilarityScore(); // 結(jié)合用戶對源視頻的偏好加權(quán)累加得分 double interest getUserInterest(userId, watchedId); scoreMap.merge(sv.getVideoId(), sim * interest, Double::sum); } } // 3. 排序取前N條返回 return sortAndLimit(scoreMap, 20); }這段邏輯寫清楚了協(xié)同過濾的“靈魂”推薦一個視頻的底氣來自它和用戶看過的視頻有多像以及用戶對看過的視頻有多喜歡。兩者缺一不可。如果只看相似度忽略了用戶偏好權(quán)重推薦的視頻容易跑偏。我還單獨用Python腳本對算法做了離線驗證輸入一組模擬的用戶行為數(shù)據(jù)輸出推薦結(jié)果的覆蓋度和平均排名。整體跑下來在數(shù)據(jù)量只有幾百條的情況下推薦結(jié)果已經(jīng)能明顯看出“同類內(nèi)容聚合”的效果。這給了我在答辯時非常大的信心因為不只是“系統(tǒng)能跑”而是“算法有效果”。4. 從零開始跑通源碼編譯、調(diào)試、驗證推薦效果4.1 環(huán)境準(zhǔn)備與工程導(dǎo)入拿到源碼壓縮包之后別急著雙擊打開工程。先把兩個基礎(chǔ)環(huán)境裝好JDK和Android Studio。工程要求的JDK版本是1.8Android Studio用較新的穩(wěn)定版本即可Gradle版本按工程自帶的wrapper來走不強配。導(dǎo)入時建議選Open an existing project直接選擇工程根目錄下的build.gradle文件。等待Gradle同步的時候Android Studio會彈提示問是否信任工程選擇信任即可。首次同步會下載依賴時間視網(wǎng)絡(luò)情況而定快則幾分鐘慢則半小時。如果卡在下載Gradle發(fā)行包那一步去gradle-wrapper.properties里把distributionUrl替換成騰訊鏡像地址這一步基本能解決90%的卡頓問題。4.2 關(guān)鍵配置項修改工程跑起來之后有兩處地方需要按實際情況改一下一是包名相關(guān)的Application ID如果你要進行差異化修改或者防止和原有調(diào)試簽名沖突可以改得個性化一點二是數(shù)據(jù)庫初始化中的數(shù)據(jù)源源碼默認(rèn)自帶了一批視頻URL和封面URL這些鏈接如果已經(jīng)失效換成你自己的本地視頻文件路徑或者公網(wǎng)可訪問的測試地址即可。視頻數(shù)據(jù)導(dǎo)入通常在DBHelper的onCreate方法里執(zhí)行里面能看到一批INSERT語句。每條視頻記錄包含視頻名稱、封面地址、播放地址、分類等字段。我實際操作時把一部分視頻換成了自己錄制的豎屏MP4文件放到手機的Download目錄再用file:///storage/emulated/0/Download/xxx.mp4這種方式作為地址填入播放依然流暢證明播放器接口的兼容性沒問題。4.3 編譯和運行時要避開的坑工程跑起來之前有幾個坑值得提前說第一次Gradle同步時如果提示SDK Platform缺失Android Studio通常會給出安裝提示直接點Install即可。如果代理導(dǎo)致依賴下載失敗檢查Gradle JVM參數(shù)里是否設(shè)置了代理按網(wǎng)絡(luò)環(huán)境調(diào)整。Java版本不一致的問題也比較常見。Gradle版本較老的工程用JDK 17跑會出現(xiàn)InvocationTargetException或者UnsupportedClassFileError這時候把Project Structure里的SDK位置指向JDK 8就能順利編譯。模擬器運行注意選擇支持GPU的虛擬設(shè)備否則視頻畫面會出現(xiàn)撕裂。真機調(diào)試相對省心但需要確認(rèn)手機開啟了開發(fā)者模式并授權(quán)USB安裝。我習(xí)慣用真機測因為ExoPlayer在模擬器上的解碼性能和真機差距不小會出現(xiàn)模擬器里一切正常、手機上某些視頻黑屏的情況所以有條件還是真機優(yōu)先。4.4 如何用真實數(shù)據(jù)驗證推薦效果系統(tǒng)跑通后最關(guān)鍵的一步是驗證推薦效果。不是“推薦列表能顯示”就叫有效果而是“不同用戶看到的內(nèi)容確實不一樣”。我的驗證方法是新建三個測試賬號分別模擬不同的觀看行為。賬號A只刷體育類視頻賬號B只看美食和旅行賬號C重點看影視剪輯。每個賬號至少產(chǎn)生8到10條行為記錄包括點贊、評論、完整瀏覽等?；氐酵扑]頁刷新對比三個賬號首頁列表的內(nèi)容分布。實測下來三個賬號首頁第一屏的重復(fù)率很低說明協(xié)同過濾確實捕捉到了不同偏好。如果刷新后發(fā)現(xiàn)列表基本雷同排查方向有兩條一是看行為記錄是否成功寫入二是看用戶表的用戶ID是否正確傳遞。因為推薦接的是當(dāng)前登錄的userId如果登錄態(tài)沒生效所有請求都會落到默認(rèn)用戶上。5. 實戰(zhàn)問題排查與優(yōu)化心得5.1 高頻問題速查表把我在跑這套源碼時遇到的高頻問題整理成了表格方便你直接對照排查問題現(xiàn)象可能原因解決方案編譯報AGP版本不兼容Gradle版本與Android Studio版本不匹配更新Gradle插件版本或按錯誤提示調(diào)整Gradle版本安裝APK后打開閃退數(shù)據(jù)庫初始化異?；騍DK權(quán)限未動態(tài)申請查看Logcat檢查onCreate里的建表SQL和權(quán)限邏輯視頻黑屏但UI正常視頻地址不可訪問 / 解碼器不支持更換為MP4測試地址或本地文件確認(rèn)網(wǎng)絡(luò)權(quán)限列表滑動卡頓掉幀圖片未緩存或加載過慢檢查Glide是否配置換用低分辨率封面圖推薦結(jié)果都一樣用戶ID未正確傳遞或行為表無數(shù)據(jù)檢查SharedPreferences保存的登錄ID和DBHelper行為寫入后臺返回頁面黑屏Activity重建后Player未正確恢復(fù)在onStart/onStop或onResume/onPause中管理play/pause5.2 性能與體驗優(yōu)化空間如果代碼已經(jīng)順利跑通接下來可以往兩個方向優(yōu)化播放流暢度和推薦新鮮度。播放流暢度方面ExoPlayer的緩存策略可以調(diào)一下默認(rèn)不分塊緩存導(dǎo)致視頻拖到進度條后面時要重新緩沖。我試過把DefaultLoadControl的緩沖時長調(diào)高開場loading時間變長但后續(xù)播放更穩(wěn)定。另外可以在滑動到下一屏之前對即將出現(xiàn)的item進行預(yù)加載也就是提前用MediaSource的preload或者手動回調(diào)prepare實測對弱網(wǎng)環(huán)境下的卡頓改善非常明顯。推薦新鮮度方面當(dāng)前的推薦結(jié)果在行為更新后需要手動刷新才會重新計算。想做到自動更新可以加個定時任務(wù)每隔幾分鐘重新執(zhí)行推薦計算并替換recommend_result表。這個改動不影響整體架構(gòu)但“定時更新推薦”這個功能寫進論文里是很加分的。5.3 課設(shè)/畢設(shè)如何在源碼基礎(chǔ)上做出差異化拿到源碼容易但所有人都交一模一樣的東西答辯就尬了。我的建議是保留骨架換一層皮再深挖一個點。所謂“換皮”是指視覺和交互體驗上的差異化。比如把豎屏信息流改成雙列瀑布流備選模式、把播放頁改造成全屏沉浸式布局、自己設(shè)計一套主題配色和圖標(biāo)體系。這些改動不需要動推薦算法的底層工作量可控但整體觀感會完全不同。所謂“深挖一個點”是指在推薦算法上做局部增強。我推薦的路徑是增加時間衰減因子?，F(xiàn)在的相似度計算和推薦評分是靜態(tài)的時間久了之后還需老視頻。給視頻的行為分?jǐn)?shù)和時間掛鉤比如7天以內(nèi)的行為權(quán)重為1.0超過30天權(quán)重衰減為0.3就能體現(xiàn)出對新鮮內(nèi)容的偏好。這個很小的問題但觸及了推薦系統(tǒng)里的“時效性”概念層面一下就有層次了。5.4 答辯時可以被問到的幾個推薦問題課程設(shè)計做完之后答辯環(huán)節(jié)不少老師會順著“推薦”往下問。提前把下面幾個問題想清楚比臨場瞎編要強得多第一個問題是你的推薦算法為什么選擇基于物品的協(xié)同過濾而不是基于用戶。回答要點可以放在短視頻場景的特征上。用戶基數(shù)大、行為稀疏計算用戶相似度成本高且不穩(wěn)定物品數(shù)量相對穩(wěn)定相似度可以離線算在線只要查表排序延遲低。第二個問題是新用戶沒有行為數(shù)據(jù)怎么辦。源碼里的兜底方案是按熱度推薦也就是按點贊數(shù)、評論數(shù)、瀏覽量的綜合值排序。你再補一句后續(xù)可以引入用戶注冊時選擇的興趣標(biāo)簽用內(nèi)容推薦做冷啟動補充這樣回答的格局就打開了。第三個問題是如何評價推薦效果好壞。不要只說“用戶覺得推得準(zhǔn)”。可以說課設(shè)環(huán)境下主要看覆蓋率推薦列表在候選視頻池中的分散程度、命中率推薦列表里被用戶點擊的比例以及多樣性首頁分類的覆蓋率這三個指標(biāo)都有現(xiàn)成的計算公式提前準(zhǔn)備一兩個計算結(jié)果截圖答辯時非常有說服力。我個人在實際操作中的體會是這個項目的核心價值不是“又拿到一份源碼”而是它把推薦算法從“公式層面”落到了“像素層面”。你能親手看著自己刷過的視頻改變首頁的順序那種反饋感比只看書上的偽代碼爽太多了。拿到源碼后不要急著原地交作業(yè)先跑通再拆掉一段核心代碼重寫最后換一套你自己的數(shù)據(jù)和界面整個過程走一遍你會比單純背十遍“協(xié)同過濾”都更明白推薦系統(tǒng)是什么。