本文整理自APMCon2016中國應用性能管理大會移動性能優化專場，映客直播iOS高級開發工程師劉凱發表了題為《映客直播 iOS App 性能優化實踐》的演講，現場解讀了映客直播iOS App的應用架構和性能優化方面的實踐經驗。具體包括App首頁直播大廳的刷新機制，直播間內用戶體驗方面的優化。
劉凱：大家下午好，我是來自映客直播的iOS工程師劉凱，今天正式的分享主要講一些偏向與客戶端上層應用開發方面的優化。主要分為三點。第一個是有關直播大廳的優化，第二是直播間優化，直播間裏面進行呈現。第三點，介紹一下私信消息模塊的整體設計。
直播大廳
首先來看一下直播列表的刷新，這一點特別的重要，因為直播列表是作為APP入口的形式存在的，所以第一點需要保證高可用，直播大廳出現了問題可以說是非常糟糕的情況。第二，很多直播存在一個問題就是當用戶看到了某一個直播封面，實際上點擊進去的時候這個直播已經結束了，這樣帶給用戶的體驗也是非常不好的。作為APP入口，它承擔了很多直播流，很多主播可以及時的進行露出吸引粉絲的關註。
在直播列表刷新的優化上，我們采用多種刷新機制相結合一個方式。第一個是 全量刷新 ，用戶登陸了以後全量拉取一些數據，第二點就是 頂部刷新 ，實際上就相當於什麽呢？TOP10一個直播流一個刷新，這個就可以根據當前App滑屏偏移來判斷。第三點是 局部刷新 ，這個策略主要來說是從用戶體驗還有服務端緩存策略兩個方面進行的。我們對於直播流進行分組，因為實際上當用戶來瀏覽直播大廳時需要對當前一些直播信息進行刷新，比如當前的直播人數。最後一點，時間間隔等信息都是服務器端可以配置的。
在 用戶體驗方面 ，我們做了一個比較常見的優化。當用戶在滑屏時有一些返回動作，這個時候就是延遲刷新當前界面。第二點，怎麽對進入直播間的速度進行優化，我們發現有一些常見的現象：當用戶點擊直播以後進入頁面會非常的慢；即使進入直播間，視頻有時候也遲遲加載不出來；第三點會收到運營的一些反饋，一些主播開播了以後，發現自己的人氣一直上不去。
這些現象由什麽造成的呢？獲取視頻流時建立網絡連接方面有一些在客戶端上層的耗時，另外直播間業務模塊非常的多，在界面初始也會有一些耗時。針對與拉取視頻流方面我們的思路就是在直播間大廳預先解析房間的視頻流地址,從而加快獲取視頻流數據的速度。然後在上層我們會對直播間很多UI模塊采用常見的冷加熱方式。這使用戶點擊的時候能夠非常快速進入到直播間看到視頻。
直播間
下面我們介紹一下直播間各個業務模塊：
這個是一個典型的直播APP業務模塊劃分。有音視頻模塊，還有公聊信息、點贊、分享等，另外還有今年映客3.0版本新上的一個連線的功能，主播可以和用戶在小視頻窗口上面進行互動，同時支持兩個用戶和主播進行互動，而且延遲相對比較低。
關於直播間優化，主要從4個方面講一下。
1、定時器事件調度
2、房間內長連接消息的處理
3、動畫展示
4、主播端的體驗優化
下圖描述的就是定時器一個事件調度，開始不同的開發人員負責不同的房間內業務模塊，使用各種各樣的定時器做一些請求，通知等等。後來使用統一的定時器，我們按照不同的時間間隔，對於這些事件進行調度處理。
下面會介紹 模塊優化 的過程。第一個公聊消息列表刷新，用戶在下方跟主播進行互動，我們遇到了一個問題，在直播間內公聊消息快速刷新會導致主線的CPU占用非常高，引起整體界面交互卡頓，後面就是怎麽一步步解決這個問題。
第一，我們使用長連接消息庫，默認就是把代理方法的執行設置到主現場。然後在做一些運營活動或者主播人氣特別高的時候，大量廣播消息就會導致客戶端收到消息過多，很容易引起CPU比較高。針對這個問題，我們的思路是將SocketIO 庫中的block執行線程設置為非主線程，緩解主線程中CPU的占用問題。
第二，我們主要是針對性能較低機型上面，會根據收到消息的速度進行實時地統計，根據收到的消息數目來動態調整公聊列表的刷新頻率。
接下來我們講一下怎麽 進行大量禮物動畫的流暢展示 ，因為這是現在直播APP裏面一個標配，這一部分我們優化思路就是下面3點。
首先，我們會對業務裏面各種各樣的禮物進行分類，收到禮物消息的時候我們就用不同優先級隊列進行管理。
然後具體到展示上面，對於點贊還有彈幕，我們使用內存池，緩存點贊和彈幕中執行動畫view/layer，以重復使用。
第三點，全屏動畫，最開始的時候我們嘗試著直接用Gif動畫。從UI到產品發布，這個時間叠代時期非常短。後來我們上了一些動畫試了效果以後，發現動畫在CPU消耗方面會特別嚴重，需要圖片的解碼包括加載之類的，非常耗性能。
然後我們逐漸對一些全屏動畫采用了Core Animation來進行一些改寫。這一塊也是需要開發人員對這個框架，對動畫裏面一些使用特別的熟悉。當然，這個也是結合UI，產品一些效果來對動畫裏面一些參數進行各種各樣的調優。
下面講一下我們是怎麽測試這個系統的？我們會分為下面幾點。
首先，就是測試環境裏面會在服務端配置一些自動的腳本，對於各種各樣的禮物進行壓力測試，會關註一些性能指標，例如CPU，內存占用等等，包括有沒有一些限制方面的問題。
第二塊是要和其他的業務模塊結合起來進行測試，這一點其實是很多時候往往會被忽略的。可能添加了一些其他業務模塊，就會發現整體APP性能不夠用。這一點是比較明顯的，我們上了美顏功能，還有今年5月份3.0版本的連麥功能的時候，直播間內有三個播放器同時進行工作，一個主播放器，兩個小播放器。這個時候如果再有很多的禮物畫面進行展示。無論是CPU，GPU壓力都是非常大的。
第三點，最終上線以前，我們導入一些線上真實廣播消息數據來對這些系統進行壓測，看一下整體APP表現形式什麽樣子。
我們在做 直播端體驗方面 的優化時發現其中非常普遍的一個現象也是很多APP都存在的一個問題，就是一個直播做了很久，好不容易上了一下熱門人氣非常高了，這個時候APP突然崩潰了怎麽辦？
這個解決方法說起來比較簡單，我們在開始直播的時候保存一些地址，還有直播間的信息。當APP真的是因為性能問題崩潰了以後。會再次啟動APP彈出繼續直播的按紐，實際上不會對房間內很多的一些業務造成太多的影響。然後，恢復效果其實就是相當於切後臺的一個操作。
第二，我們配合後端做的一個優化，在運營時房間內的廣告消息壓力是非常大的。主要的現象有以下兩點，包括禮物持續刷屏，實際上直播體驗是非常糟糕的。大家可以看到這一張圖，就是前一段時間裏約奧運的洪荒之力。
針對這個運營活動的壓力，我們主要的解決思路一個是采用服務降級，會在協議上和服務端做一些商定，服務端可以下發很多限制客戶端公聊和禮物消息發送頻率的一些命令。然後，客戶端這一部分我們也會進行一些限制例如點贊及部分禮物的動畫展示，盡可能保證主播端的體驗。
接下來主要講下映客在減輕服務端並發請求方面的優化。
關於用戶關註關系的拉取。當你進入一個直播間的時候，都需要拉取上面的用戶列表中的關註關系，主播結束直播時可能一下子有非常多用戶拉取和主播的關註關系。關於這個場景，實際上會給服務端造成非常大的壓力。
還有推送消息這一塊。當一些明星用戶進行開播全量推送時，可能會喚起大量客戶端同時拉取大廳直播列表 。關於這一方面的解決思路，主要是采取緩存的策略。我們會對用戶profile，關註關系等進行緩存，收到直播推送的時候，不立即刷新直播列表，延遲到退出直播間後再啟動大廳刷新機制。
最後講一點，就是客戶端首次安裝啟動的問題，當用戶首次下載映客了以後，點擊登陸時會出現卡頓，這個問題的原因在於什麽呢？當客戶端啟動的時候需要下載大量的圖片資源，包括對於各種各樣的禮物資源，還有很多等級資源進行請求。這個過程當中有很多大量的文件操作，這就需要我們對部分資源首先進行內置保證基本的使用，另外對於資源進行一個增量下載變現。
上面就是直播間裏面一些優化的點。最後簡單講一下私信消息模塊的整體設計，我們沒有用第三方，而是用自己的一個整套方案。
私信消息
在私信裏面也是涉及到一些送禮，定制化的東西，我們想做的是提高私信聊天頁面的打開速度和提供一個好的瀏覽消息體驗，只需要在內存裏面緩存少量的幾十條數據來進行整個展示。滑屏瀏覽時，動態更新緩存內容，這樣用戶點擊某一個人進入到聊天界面，體驗會得到優化。
來自：https://blog.tingyun.com/web/article/detail/1144
Tags:
文章來源：