優化信息流很麻煩？三招教你輕鬆搞定

隨着移動互聯網的快速發展，大多數人已經習慣用手機獲取各種信息。但信息量的不斷增大，各類低質重複信息正嚴重影響着用戶體驗。所謂信息流性能優化，就是利用「大數據+人工」的方式在信息的數量和質量上控制展示在用戶眼前的信息。

本文將由新浪微博客戶端Feed組技術專家張善祿對微博的信息流優化解決方案進行解讀。主要包括三個部分：流服務、性能優化、性能監控。

流服務

微博信息流承載了視頻、直播、文章等許多業務，信息流和這些業務間的耦合比較嚴重。這種關係不但致使信息流維護成本增長，也在必定程度上影響業務方的開發。

爲了解決上述問題，微博開發了流服務框架，主要有兩個目標：一是解決耦合問題實現業務插件化，二是支持微博內部其餘流式頁面的快速開發。

ViewModel是這個模型的關鍵對象，一方面負責管理View的狀態，另外一方面負責將View中的事件包裝成一個Action。Action用來描述一個業務事件，它包括類型和數據，一個Action最終會交給ActionExecutor來處理，ActionExecutor負責處理具體的業務邏輯。

因爲View和ViewModel不處理具體的業務邏輯，所以複用性很好。在不一樣的頁面，每每具體的業務邏輯也不一樣，只需將ActionExecutor替換掉便可。

流服務不但解決了耦合的問題，也爲性能優化打下了良好的基礎。

性能優化

一條微博能夠自上而下地劃分爲頭部、文字、視頻、標籤、底部按紐等16塊區域，其中較特殊的區域有轉發微博區域和Card區域。轉發微博區域展現的是用戶轉發的微博，一樣能夠自上而下劃分爲16塊區域；Card區能夠展現視頻、直播、大圖等，不一樣的微博展現的Card類型不一樣，目前Card區域的類型大概有30多種。

因而可知微博View十分複雜，這致使view層級較深而且BindView開銷較大。咱們解決這些問題的思路是化繁爲簡，按照上述劃分的區域，將微博拆分紅一一對應的view，同時咱們會爲每一個拆分好的View建立ViewModel。

拆分完成之後，爲了解決微博總體的點擊、背景等問題，咱們定義了VirtualView的概念，將點擊事件、背景等信息放到VirtualView中進行處理。

爲了優化BindView的開銷，微博在會子線程中對耗時的業務邏輯進行預處理。

此外，針對某些建立開銷較大的view，微博開發了預加載view的機制，在建立完ViewModel後，根據配置來決定ViewModel對應的view是否須要預加載，這樣在建立view時可直接從ViewCache中獲取。

性能監控

性能監控系統能夠發現並定位性能問題，評估優化效果。微博性能監控主要包括CPU、內存、FPS、卡頓。

性能監控會貫穿微博開發過程當中的每個環節。開發階段能夠利用性能監控系統實時查看性能狀態；提代碼階段會有自動化性能測試防止有問題的代碼進版；內測階段會有性能報告來評估新版本的性能問題；上線後，能夠幫助解決線上用戶的性能問題。

對於微博信息流優化實踐，你以爲有哪些值得借鑑和能夠改進的地方呢？歡迎留言說出您的見解