1.在今日頭條中，每次下拉刷新數(shù)據(jù)都不一樣。正常的話，會把新聞存在一個表里面，會去數(shù)據(jù)在最早的放在前面，再刷新頂部數(shù)據(jù)也是不會變的。她社區(qū)也是同樣的道理。（不討論今日頭條的推薦算法）
3 回答
HUH函數(shù)
TA貢獻1836條經(jīng)驗 獲得超4個贊
如果用到分頁，而且數(shù)據(jù)更新的很快，比如像新浪微博，數(shù)據(jù)刷新很快，如果用傳統(tǒng)的 page = n
這樣的分頁肯定是不行的，這樣肯定用戶體驗差，因為如果我在這個頁面停留一段時間，然后其他人發(fā)布了微博，我在下拉加載就會有重復數(shù)據(jù)，解決就是用 當前頁面的最后一條 微博 id 來分頁，每次查詢數(shù)據(jù)庫 用當前 微博 id 查詢，例如 where = id > 100 limit 10 這樣解決，如果是上拉刷新 就用 where = id < 100 limit 10 。這是 關系數(shù)據(jù)庫（MySQL）的解決方案，我也有一個問題，如果我用 redis 做緩存的話，這樣的查詢辦不到怎么解決，也不知道新浪這樣的是怎么解決的，還是這樣的數(shù)據(jù)不能用 nosql 數(shù)據(jù)存儲
不負相思意
TA貢獻1777條經(jīng)驗 獲得超10個贊
個人覺得應該是使用的分頁原理吧，第一次下拉刷新就對應的是第一頁，第二次是第二頁，然后后端根據(jù)這個次數(shù)查詢數(shù)據(jù)庫
烙印99
TA貢獻1829條經(jīng)驗 獲得超13個贊
根據(jù)獲取到數(shù)據(jù)，每條記錄的key判斷已渲染的新聞中有沒有相同的來過濾，再進行渲染。
PS：這個事情交給客戶端來處理是很容易的，在服務器端處理就很麻煩。
添加回答
舉報
0/150
提交
取消