編輯導語：?feed是將用戶主動訂閱的若干消息源組合在一起形成內容聚合器，幫助用戶持續地獲取最新的訂閱源內容；feed流即持續更新并呈現給用戶內容的信息流；本文作者介紹了Feed流產品的重用機制，我們一起來看一下。

作為一名產品經理，在體驗產品時經常會遇到一些bug，這時開發會說能否錄屏復現一下bug。

以最常用的新聞feed流為例，同一個feed你之前發現有問題（比如UI錯位、數據錯亂）等，再刷回這個feed卻沒有問題了。

????????????????? ? [步驟一]發現Feed 1有bug

?[步驟二]下滑看其他內容

[步驟三]刷回Feed1，發現bug不見了

這時場面就會很尷尬，開發覺得你找事，而你剛才確實發現有bug。

出現上面問題，我們需要學習一下feed流本身是怎么實現的。

• 我們有一個基本的共識：每一個feed要想展示出來，都是需要被創建的。
• 我們思考一下，既然feed需要被創建，那它被創建的時機有哪幾種可能呢？

一、當我刷到n條內容時，頁面立馬就創建n個feed

這種最直觀也最簡單：

但是一次性創建的操作是不可取的。要知道每創建一個feed都需要消耗內存（可以理解成每買一個包包放家里，家里的空間都會少很多）。

那么類似今日頭條、知乎、視頻號這種產品，刷了半小時后很可能你已經看了上百個內容；如果手機這時也創建了上百個feed，那么隨著你使用時間越長，手里機創建的feed會越多（包包買得越來越多），手機內存空間會漸漸不夠用（家里可用房間會越來越少），而手機會越來越卡，直到內存完全被占用而卡死（家里的空間被用完）。

但實際上我們刷feed流類的產品時，并沒有出現所描述的隨著使用時間變長而越來越卡頓的情況，所以“刷到n條內容時，頁面立馬就創建n個feed”這種創建方式不可取。

二、只有當我即將看到某條內容時，才創建feed來進行展示

這種方案可以有效避免創建太多feed導致系統內存用光的問題；以知乎為例，平時我們使用的手機最多展示5-10條知乎的內容，所以系統最多只需要占用5-10條feed的空間。

用包包來理解就是：家里只有一面墻可以放包包，放包包的上限是10個，每次我們買來新的包包，然后把舊的包包給扔掉，這樣就可以始終保持家里有足夠的放包空間。

對價格敏感的產品已經發現了方案二的問題，為啥我每次買到新的包包，都要買舊的包包給扔掉呀？那豈不是太浪費錢了；類比到手機App上就是太浪費手機的計算能力了，尤其是當你快速滑動手機屏幕時，就會出現上百條feed被創建，同時上百條feed被銷毀，暴殄天物啊。

所以，第二種“只有當我即將看到某條內容時，才創建feed來進行展示”實際上也不是最可行的方案。

那么怎么樣既省內存空間，又避免重復的計算開銷呢？

三、重用機制

還以買包包為例，實際上每個包包的主要區別是表面上的區別（比如紋理、顏色等），包包的主要功能基本上都是相似的。

遂在方案二的基礎上，當我買夠了超過一面墻的包包后，此時如果我又看上了新包包，如果“再花錢買一個新的，然后把之前舊的給扔掉”（方案二）就太浪費了。

所以我們靈機一動發現新包包和舊包包，主要功能基本一樣；那么我只要請人來幫我把舊包包的顏色、紋理改裝成和新包包的樣式一樣，這樣用最小的成本獲取了新的包包。

實際上，Feed流背后也有著類似重用的機制，系統會先創建足夠屏幕展示的feed；而當你再向下滑動手機時，會把舊feed拿過來進行重用，把數據更新即可。

明白feed流有重用機制，我們就可以解答最開始的問題：“以最常用的新聞feed流為例，同一個feed你之前發現有問題（比如UI錯位、數據錯亂）等，再刷回這個feed卻沒有問題了?！?/p>

之前看到錯位的feed A，和你重新刷回的feed A，其樣式雖然一樣，但其本質已經變了。

你第一次看到的feed A，是系統最開始創建的feed A，而你重新刷回看到的feed A，已經是重用了別人的feed，只是更新了feed A的數據而已。

還是用包包舉例：

房間里一共可以放下三個包包，按時間線于是你最初買了LV、Gucci、PRADA這三個包包。

當你想擁有Chanel包包時，這時因為LV包包是最先買的，所以會把LV包包改裝成Chanel包包，現在柜子里就變成:Gucci、PRADA、Chanel這三個包包。

過了幾天你又想要之前的LV包包了，于是按時間線這時會把Channel包包給改裝回LV包包，重新變成：LV、Gucci、PRADA這三個包包。

雖然這時還是LV、Gucci、PRADA這三個包包，但實際上第一個LV包包已經不是最新的了，它已經從新品變成了二手貨。

這種機制可以用古希臘哲學家赫拉克利特所說“人不能兩次踏進同一條河流”進行概括，下次當你遇到feed流產品bug不可復現時，可以從feed流的重用機制進行思考。

公眾號：和產品經理聊技術

本文由 @和產品經理聊技術 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。