望本文可以帶給大家一個(gè)相對(duì)全局的視角看待卡頓問題，認(rèn)識(shí)到卡頓是什么、卡頓的成因、卡頓的分類、卡頓的優(yōu)化和一些經(jīng)驗(yàn)積累，有的放矢地解決 App 流暢性問題。接下來會(huì)從以下五個(gè)方面進(jìn)行講述：

?什么是卡頓

?為什么會(huì)發(fā)生卡頓

?如何評(píng)價(jià)卡頓

?如何優(yōu)化卡頓

?加入我們

1. 什么是卡頓

卡頓，顧名思義就是用戶體感界面不流暢。我們知道手機(jī)的屏幕畫面是按照一定頻率來刷新的，理論上講，24 幀的畫面更新就能讓人眼感覺是連貫的。但是實(shí)際上，這個(gè)只是針對(duì)普通的視頻而言。對(duì)于一些強(qiáng)交互或者較為敏感的場(chǎng)景來說，比如游戲，起碼需要 60 幀，30 幀的游戲會(huì)讓人感覺不適；位移或者大幅度動(dòng)畫 30 幀會(huì)有明顯頓挫感；跟手動(dòng)畫如果能到 90 幀甚至 120 幀，會(huì)讓人感覺十分細(xì)膩，這也是近來廠商主打高刷牌的原因。

對(duì)于用戶來說，從體感角度大致可以將卡頓分為以下幾類：

這些體驗(yàn)對(duì)于用戶可以說是非常糟糕的，甚至?xí)鸶泄俚臒┰辏M(jìn)而導(dǎo)致用戶不愿意繼續(xù)停留在我們的 App。可以說，流暢的體驗(yàn)對(duì)于用戶來說至關(guān)重要。

2. 為什么會(huì)發(fā)生卡頓

用戶體感的卡頓問題原因很多，且常常是一個(gè)復(fù)合型的問題，為了聚焦，這里暫只考慮真正意義上的掉幀卡頓。

2.1 繞不開的 VSYNC

我們通常會(huì)說，屏幕的刷新率是 60 幀，需要在 16ms 內(nèi)做完所有的操作才不會(huì)造成卡頓。但是這里需要明確幾個(gè)基本問題：

1. 為什么是 16ms？
2. 16ms 內(nèi)都需要完成什么？
3. 系統(tǒng)如何盡力保證任務(wù)在 16ms 內(nèi)完成？
4. 16ms 內(nèi)沒有完成，一定會(huì)造成卡頓嗎？

這里先回答第一個(gè)問題：為什么是 16ms。早期的 Android 是沒有 vsync 機(jī)制的，CPU 和 GPU 的配合也比較混亂，這也造成著名的 tearing 問題，即 CPU/GPU 直接更新正在顯示的屏幕 buffer 造成畫面撕裂。后續(xù) Android 引入了雙緩沖機(jī)制，但是 buffer 的切換也需要一個(gè)比較合適的時(shí)機(jī)，也就是屏幕掃描完上一幀后的時(shí)機(jī)，這也就是引入 vsync 的原因。

早先一般的屏幕刷新率是 60fps，所以每個(gè) vsync 信號(hào)的間隔也是 16ms，不過隨著技術(shù)的更迭以及廠商對(duì)于流暢性的追求，越來越多 90fps 和 120fps 的手機(jī)面世，相對(duì)應(yīng)的間隔也就變成了 11ms 和 8ms。

那既然有了 VSYNC，誰(shuí)在消費(fèi) VSYNC？其實(shí) Android 的 VSYNC 消費(fèi)者有兩個(gè)，也就對(duì)應(yīng)兩類 VSYNC 信號(hào)，分別是 VSYNC-app 和 VSYNC-sf，所對(duì)應(yīng)的也是上層 view 繪制和 surfaceFlinger 的合成，具體的我們接下來詳細(xì)說。

這里還有一些比較有意思的點(diǎn)，有些廠商會(huì)有 vsync offset 的設(shè)計(jì)，App 和 sf 的 vsync 信號(hào)之間是有偏移量的，這也在一定程度上使得 App 和 sf 的協(xié)同效應(yīng)更好。

2.2 View 顛沛流離的一生

在講下一 part 之前先引入一個(gè)話題：

一個(gè) view 究竟是如何顯示在屏幕上的？

我們一般都比較了解 view 渲染的三大流程，但是 view 的渲染遠(yuǎn)不止于此：

此處以一個(gè)通用的硬件加速流程來表征

1. Vsync 調(diào)度：很多同學(xué)的一個(gè)認(rèn)知誤區(qū)在于認(rèn)為 vsync 是每 16ms 都會(huì)有的，但是其實(shí) vsync 是需要調(diào)度的，沒有調(diào)度就不會(huì)有回調(diào)；
2. 消息調(diào)度：主要是 doframe 的消息調(diào)度，如果消息被阻塞，會(huì)直接造成卡頓；
3. input 處理：觸摸事件的處理；
4. 動(dòng)畫處理：animator 動(dòng)畫執(zhí)行和渲染；
5. view 處理：主要是 view 相關(guān)的遍歷和三大流程；
6. measure、layout、draw：view 三大流程的執(zhí)行；
7. DisplayList 更新：view 硬件加速后的 draw op；
8. OpenGL 指令轉(zhuǎn)換：繪制指令轉(zhuǎn)換為 OpenGL 指令；
9. 指令 buffer 交換：OpenGL 的指令交換到 GPU 內(nèi)部執(zhí)行；
10. GPU 處理：GPU 對(duì)數(shù)據(jù)的處理過程；
11. layer 合成：surface buffer 合成屏幕顯示 buffer 的流程；
12. 光柵化：將矢量圖轉(zhuǎn)換為位圖；
13. Display：顯示控制；
14. buffer 切換：切換屏幕顯示的幀 buffer；

Google 將這個(gè)過程劃分為：其他時(shí)間/VSync 延遲、輸入處理、動(dòng)畫、測(cè)量/布局、繪制、同步和上傳、命令問題、交換緩沖區(qū)。也就是我們常用的 GPU 嚴(yán)格模式，其實(shí)道理是一樣的。到這里，我們也就回答出來了第二個(gè)問題：16ms 內(nèi)都需要完成什么？

準(zhǔn)確地說，這里仍可以進(jìn)一步細(xì)化：16ms 內(nèi)完成 APP 側(cè)數(shù)據(jù)的生產(chǎn)；16ms 內(nèi)完成 sf layer 的合成

View 的視覺效果正是通過這一整條復(fù)雜的鏈路一步步展示出來的，有了這個(gè)前提，那就可以得出一個(gè)結(jié)論：上述任意鏈路發(fā)生卡頓，均會(huì)造成卡頓。

2.3 生產(chǎn)者和消費(fèi)者

我們?cè)倩氐?Vsync 的話題，消費(fèi) Vsync 的雙方分別是 App 和 sf，其中 App 代表的是生產(chǎn)者，sf 代表的是消費(fèi)者，兩者交付的中間產(chǎn)物則是 surface buffer。

再具體一點(diǎn)，生產(chǎn)者大致可以分為兩類，一類是以 window 為代表的頁(yè)面，也就是我們平時(shí)所看到的 view 樹這一套；另一類是以視頻流為代表的可以直接和 surface 完成數(shù)據(jù)交換的來源，比如相機(jī)預(yù)覽等。

對(duì)于一般的生產(chǎn)者和消費(fèi)者模式，我們知道會(huì)存在相互阻塞的問題。比如生產(chǎn)者速度快但是消費(fèi)者速度慢，亦或是生產(chǎn)者速度慢消費(fèi)者速度快，都會(huì)導(dǎo)致整體速度慢且造成資源浪費(fèi)。所以 Vsync 的協(xié)同以及雙緩沖甚至三緩沖的作用就體現(xiàn)出來了。

思考一個(gè)問題：是否緩沖的個(gè)數(shù)越多越好？過多的緩沖會(huì)造成什么問題？

答案是會(huì)造成另一個(gè)嚴(yán)重的問題：lag，響應(yīng)延遲

這里結(jié)合 view 的一生，我們可以把兩個(gè)流程合在一起，讓我們的視角再高一層：

2.4 機(jī)制上的保護(hù)

這里我們來回答第三個(gè)問題，從系統(tǒng)的渲染架構(gòu)上來說，機(jī)制上的保護(hù)主要有幾方面：

1. Vsync 機(jī)制的協(xié)同；
2. 多緩沖設(shè)計(jì)；
3. surface 的提供；
4. 同步屏障的保護(hù)；
5. 硬件繪制的支持；
6. 渲染線程的支持；
7. GPU 合成加速；

這些機(jī)制上的保護(hù)在系統(tǒng)層面最大程度地保障了 App 體驗(yàn)的流暢性，但是并不能幫我們徹底解決卡頓。為了提供更加流暢的體驗(yàn)，一方面，我們可以加強(qiáng)系統(tǒng)的機(jī)制保護(hù)，比如 FWatchDog；另一方面，需要我們從 App 的角度入手，治理應(yīng)用內(nèi)的卡頓問題。

2.5 再看卡頓的成因

經(jīng)過上面的討論，我們得出一個(gè)卡頓分析的核心理論支撐：渲染機(jī)制中的任何流轉(zhuǎn)過程發(fā)生異常，均會(huì)造成卡頓。

那么接下來，我們逐個(gè)分析，看看都會(huì)有哪些原因可能造成卡頓。

2.5.1 渲染流程

1. Vsync 調(diào)度：這個(gè)是起始點(diǎn)，但是調(diào)度的過程會(huì)經(jīng)過線程切換以及一些委派的邏輯，有可能造成卡頓，但是一般可能性比較小，我們也基本無(wú)法介入；
2. 消息調(diào)度：主要是 doframe Message 的調(diào)度，這就是一個(gè)普通的 Handler 調(diào)度，如果這個(gè)調(diào)度被其他的 Message 阻塞產(chǎn)生了時(shí)延，會(huì)直接導(dǎo)致后續(xù)的所有流程不會(huì)被觸發(fā)。這里直播建立了一個(gè) FWtachDog 機(jī)制，可以通過優(yōu)化消息調(diào)度達(dá)到插幀的效果，使得界面更加流暢；
3. input 處理：input 是一次 Vsync 調(diào)度最先執(zhí)行的邏輯，主要處理 input 事件。如果有大量的事件堆積或者在事件分發(fā)邏輯中加入大量耗時(shí)業(yè)務(wù)邏輯，會(huì)造成當(dāng)前幀的時(shí)長(zhǎng)被拉大，造成卡頓。抖音基礎(chǔ)技術(shù)同學(xué)也有嘗試過事件采樣的方案，減少 event 的處理，取得了不錯(cuò)的效果；
4. 動(dòng)畫處理：主要是 animator 動(dòng)畫的更新，同理，動(dòng)畫數(shù)量過多，或者動(dòng)畫的更新中有比較耗時(shí)的邏輯，也會(huì)造成當(dāng)前幀的渲染卡頓。對(duì)動(dòng)畫的降幀和降復(fù)雜度其實(shí)解決的就是這個(gè)問題；
5. view 處理：主要是接下來的三大流程，過度繪制、頻繁刷新、復(fù)雜的視圖效果都是此處造成卡頓的主要原因。比如我們平時(shí)所說的降低頁(yè)面層級(jí)，主要解決的就是這個(gè)問題；
6. measure/layout/draw：view 渲染的三大流程，因?yàn)樯婕暗奖闅v和高頻執(zhí)行，所以這里涉及到的耗時(shí)問題均會(huì)被放大，比如我們會(huì)降不能在 draw 里面調(diào)用耗時(shí)函數(shù)，不能 new 對(duì)象等等；
7. DisplayList 的更新：這里主要是 canvas 和 displaylist 的映射，一般不會(huì)存在卡頓問題，反而可能存在映射失敗導(dǎo)致的顯示問題；
8. OpenGL 指令轉(zhuǎn)換：這里主要是將 canvas 的命令轉(zhuǎn)換為 OpenGL 的指令，一般不存在問題。不過這里倒是有一個(gè)可以探索的點(diǎn)，會(huì)不會(huì)存在一類特殊的 canvas 指令，轉(zhuǎn)換后的 OpenGL 指令消耗比較大，進(jìn)而導(dǎo)致 GPU 的損耗？有了解的同學(xué)可以探討一下；
9. buffer 交換：這里主要指 OpenGL 指令集交換給 GPU，這個(gè)一般和指令的復(fù)雜度有關(guān)。一個(gè)有意思的事兒是這里一度被我們作為線上采集 GPU 指標(biāo)的數(shù)據(jù)源，但是由于多緩沖的因素?cái)?shù)據(jù)準(zhǔn)確度不夠被放棄了；
10. GPU 處理：顧名思義，這里是 GPU 對(duì)數(shù)據(jù)的處理，耗時(shí)主要和任務(wù)量和紋理復(fù)雜度有關(guān)。這也就是我們降低 GPU 負(fù)載有助于降低卡頓的原因；
11. layer 合成：這里主要是 layer 的 compose 的工作，一般接觸不到。偶爾發(fā)現(xiàn) sf 的 vsync 信號(hào)被 delay 的情況，造成 buffer 供應(yīng)不及時(shí)，暫時(shí)還不清楚原因；
12. 光柵化/Display：這里暫時(shí)忽略，底層系統(tǒng)行為；
13. Buffer 切換：主要是屏幕的顯示，這里 buffer 的數(shù)量也會(huì)影響幀的整體延遲，不過是系統(tǒng)行為，不能干預(yù)。

2.5.2 視頻流

除了上述的渲染流程引起的卡頓，還有一些其他的因素，典型的就是視頻流。

1. 渲染卡頓：主要是 TextureView 渲染，textureview 跟隨 window 共用一個(gè) surface，每一幀均需要一起協(xié)同渲染并相互影響，UI 卡頓會(huì)造成視頻流卡頓，視頻流的卡頓有時(shí)候也會(huì)造成 UI 的卡頓；
2. 解碼：解碼主要是將數(shù)據(jù)流解碼為 surface 可消費(fèi)的 buffer 數(shù)據(jù)，是除了網(wǎng)絡(luò)外最重要的耗時(shí)點(diǎn)。現(xiàn)在我們一般都會(huì)采用硬解，比軟解的性能高很多。但是幀的復(fù)雜度、編碼算法的復(fù)雜度、分辨率等也會(huì)直接導(dǎo)致解碼耗時(shí)被拉長(zhǎng)；
3. OpenGL 處理：有時(shí)會(huì)對(duì)解碼完成的數(shù)據(jù)做二次處理，這個(gè)如果比較耗時(shí)會(huì)直接導(dǎo)致渲染卡頓；
4. 網(wǎng)絡(luò)：這個(gè)就不再贅述了，包括 DNS 節(jié)點(diǎn)優(yōu)選、cdn 服務(wù)、GOP 配置等；
5. 推流異常：這個(gè)屬于數(shù)據(jù)源出了問題，這里暫時(shí)以用戶側(cè)的視角為主，暫不討論。

2.5.3 系統(tǒng)負(fù)載

1. 內(nèi)存：內(nèi)存的吃緊會(huì)直接導(dǎo)致 GC 的增加甚至 ANR，是造成卡頓的一個(gè)不可忽視的因素；
2. CPU：CPU 對(duì)卡頓的影響主要在于線程調(diào)度慢、任務(wù)執(zhí)行的慢和資源競(jìng)爭(zhēng)，比如降頻會(huì)直接導(dǎo)致應(yīng)用卡頓；
3. GPU：GPU 的影響見渲染流程，但是其實(shí)還會(huì)間接影響到功耗和發(fā)熱；
4. 功耗/發(fā)熱：功耗和發(fā)熱一般是不分家的，高功耗會(huì)引起高發(fā)熱，進(jìn)而會(huì)引起系統(tǒng)保護(hù)，比如降頻、熱緩解等，間接的導(dǎo)致卡頓。

2.6 卡頓的分類

我們此處再整體整理并歸類，為了更完備一些，這里將推流也放了上來。在一定程度上，我們遇到的所有卡頓問題，均能在這里找到理論依據(jù)，這也是指導(dǎo)我們優(yōu)化卡頓問題的理論支撐。

3. 如何評(píng)價(jià)卡頓

3.1 線上指標(biāo)

3.2 線下指標(biāo)

Diggo 是字節(jié)自研的一個(gè)開放的開發(fā)調(diào)試工具平臺(tái)，是一個(gè)集「評(píng)價(jià)、分析、調(diào)試」為一體的，一站式工具平臺(tái)。內(nèi)置性能測(cè)評(píng)、界面分析、卡頓分析、內(nèi)存分析、崩潰分析、即時(shí)調(diào)試等基礎(chǔ)分析能力，可為產(chǎn)品開發(fā)階段提供強(qiáng)大助力。

4. 如何優(yōu)化卡頓

4.1 常用的工具

4.1.1 線上工具

4.1.2 線下工具

4.2 常用的思路

這里主要針對(duì) UI 卡頓和 UI/流相互影響打來的卡頓。

對(duì)于 UI 卡頓來說，我們手握卡頓優(yōu)化的 8 板大斧子，所向披靡：

1. 下線代碼；
2. 減少執(zhí)行次數(shù)；
3. 異步；
4. 打散；
5. 預(yù)熱；
6. 復(fù)用；
7. 方案優(yōu)化；
8. 硬件加速；

總體思路就是「能不干就不干、能少干就少干、能早點(diǎn)干就早點(diǎn)兒干、能晚點(diǎn)兒干就晚點(diǎn)兒干、能讓別人干就讓別人干、能干完一次當(dāng) 10 次就只干一次，實(shí)在不行，再考慮自己大干一場(chǎng)」。

這里例舉出一些常見的優(yōu)化思路，注意這一定也不可能是全部，如果有其他好的優(yōu)化思路，我們可以一起交流。

4.3 一些做過的事兒

4.3.1 解決 UI 卡頓引起的流卡頓

直播對(duì)于 SurfaceView 的切換是一個(gè)長(zhǎng)期的專項(xiàng)，分為多期逐步將 SurfaceView 在直播全量落地，場(chǎng)景覆蓋秀場(chǎng)直播、聊天室、游戲直播、電商直播、媒體直播等，業(yè)務(wù)上對(duì)于滲透率和停留時(shí)長(zhǎng)有比較顯著的收益，同時(shí)功耗的收益也很可觀。

這里是一個(gè)權(quán)衡的問題，SurfaceView 的兼容性問題 pk 帶來的收益是否能打平，一般來說，越是復(fù)雜的業(yè)務(wù)場(chǎng)景，收益約大。

4.3.2 解決 message 調(diào)度

FWatchDog 是基于對(duì) MessageQueue 的調(diào)度策略和同步屏障原理，以均幀耗時(shí)為閾值判定丟幀后主動(dòng)在 MessageQueue 中插入同步屏障，保證渲染異步 message 和 doframe 的優(yōu)先執(zhí)行，達(dá)到一種渲染插幀的效果，同時(shí)具備 ANR 自動(dòng)恢復(fù)同步屏障的能力，保障打散的有效。

所以 FWatchDog 和打散是好的搭檔，能產(chǎn)生 1+1 大于 2 的效果。

4.3.3 減少執(zhí)行次數(shù)

一個(gè)典型的應(yīng)用場(chǎng)景就是滑動(dòng)場(chǎng)景的 GC 抑制，能夠顯著提高用戶上下滑的使用體驗(yàn)。這個(gè)場(chǎng)景相信每個(gè)業(yè)務(wù)都會(huì)存在，特別是存在大量遍歷的邏輯，優(yōu)化效果明顯。

4.3.4 代碼下線

一些老的框架、無(wú)用的邏輯以及存在性不高的代碼都可以下線，這里基本業(yè)務(wù)強(qiáng)相關(guān)，就不舉具體的例子了。

4.3.5 解決耗時(shí)函數(shù)（打散/異步）

首先是打散，直播做了很多 task 的拆分以及打散，第一可以減輕當(dāng)前渲染幀的耗時(shí)壓力，第二可以和 FWatchDog 結(jié)合達(dá)到插幀的效果。這里其實(shí)還可以控制 task 的執(zhí)行優(yōu)先級(jí)，包括隊(duì)列的插隊(duì)等，總之 MessageQueue 的合理調(diào)度是很有必要的。

異步的使用也相對(duì)比較多，一個(gè)埋點(diǎn)日志的框架，以及一些 inflate 的加載等，都可以使用異步來解決卡頓問題。

4.3.6 預(yù)熱

直播提供了一個(gè)預(yù)熱框架，可以讓直播內(nèi)部的一次性成本邏輯得到在宿主側(cè)執(zhí)行的機(jī)會(huì)，同時(shí)提供完備的隊(duì)列優(yōu)先級(jí)管理、同步異步管理和 task 生命周期管理，降低直播內(nèi)部首次加載的卡頓問題。

4.3.7 硬件加速

拉高硬件的運(yùn)行性能，比如 CPU 頻率、GPU 頻率、線程綁大核以及網(wǎng)絡(luò)相關(guān)的調(diào)優(yōu)，從底層提高 App 的運(yùn)行體驗(yàn)。

5. 加入我們

直播客戶端技術(shù)團(tuán)隊(duì)是一個(gè)集體驗(yàn)優(yōu)化、平臺(tái)建設(shè)、跨端、端智能、穩(wěn)定性為一體的綜合性團(tuán)隊(duì)，團(tuán)隊(duì)氛圍 nice，技術(shù)成長(zhǎng)快，有充足的自由度發(fā)揮自己的特長(zhǎng)，為億級(jí) DAU 產(chǎn)品保駕護(hù)航，也面臨更加豐富多樣的挑戰(zhàn)，每一行代碼都會(huì)讓數(shù)億的用戶體驗(yàn)變得更好！現(xiàn)誠(chéng)邀各位英才加入，對(duì)這些方向感興趣的同學(xué)都可以來聊一聊，內(nèi)推鏈接：「鏈接」

什么會(huì)卡？

之前發(fā)過這個(gè)視頻，總有人在評(píng)論區(qū)或者發(fā)私信問我為什么卡？為什么卡？我不知道你套用了什么軟件，不知道你里面怎么設(shè)置的，甚至有的朋友是邊玩游戲邊直播的，又不知道你玩的什么游戲。本身有的游戲?qū)﹄娔X的配置要求就很高，只能怎么樣來分析？

·首先打開任務(wù)管理器，直播的時(shí)候來看CPU跑到了多少。如果CPU到了八十幾、九十幾甚至有的到了100，肯定100%就卡了，到了100CPU都跑到100了能不卡嗎？

·點(diǎn)開任務(wù)管理器去看一下自己的CPU，檢查一下自己的網(wǎng)絡(luò)，這個(gè)地方檢查下網(wǎng)絡(luò)上行是多少，一般90%就是電腦跟網(wǎng)絡(luò)的問題。

·如果CPU跑得很高了怎么來處理？首先來看一下套用了一些什么軟件，比如現(xiàn)在套用了YY，把YY點(diǎn)出來，然后把這個(gè)放一邊，看CPU的變化，CPU現(xiàn)在是七十幾，就檢查設(shè)置的這些軟件設(shè)置的幀率是多少，把它變成30。

·再來看一下，這個(gè)先不管，現(xiàn)在是不是就降下來了一點(diǎn)了？比如現(xiàn)在又套用了OBS，OBS現(xiàn)在停止，然后來設(shè)置一下輸出設(shè)置的碼率是多少，分辨率是多少。比如現(xiàn)在把它改成正常的抖音1080，再來看一下，確認(rèn)，這里啟動(dòng)是不是又下來了一點(diǎn)？

·直播伴侶再來看一下，現(xiàn)在看一下攝像頭，誰(shuí)知道是多少？60幀，給它改成30幀。

做實(shí)驗(yàn)的目的是什么？就是要告訴你們，首先去看電腦配置，電腦配置套用了什么軟件，CPU跑到多少了，然后去看一下自己設(shè)置的東西。比如現(xiàn)在是不是下來了40多了、50多了，開始都是多少，還不行，把這些都設(shè)低一點(diǎn)，這個(gè)變成30，高級(jí)這里選個(gè)低檔位，中檔位，現(xiàn)在是不是又下來了一些？

所以這些東西不看電腦配置，不看是怎么設(shè)置的，不看套用了什么軟件，問我為什么卡？為什么卡？我不是神仙，不知道，以后不要來問我，評(píng)論區(qū)也好，私信也好，尤其是那些玩游戲的就不要來問我為什么卡，不知道玩的什么游戲，不知道電腦配置，不要來問我。

播間設(shè)置設(shè)置，直播卡頓是什么原因？

在直播的時(shí)候，如果直播畫面出現(xiàn)延遲怎么辦？首先要去檢查電腦的配置，如果電腦配置太低的話，就會(huì)出現(xiàn)掉幀、卡頓以及音畫不同步的情況。那如何知道是不是電腦的問題？很簡(jiǎn)單，去直播伴侶下方找到實(shí)時(shí)幀率顯示，如果說低于正常選擇的一個(gè)幀率，就是你的電腦配置不行。

其次就是網(wǎng)絡(luò)寬帶速度不夠，那在直播伴侶中點(diǎn)擊網(wǎng)絡(luò)測(cè)速，看一下它的上行速度是不是大于50。如果說上行速度大于50，那直播網(wǎng)絡(luò)是完全沒有問題的。為什么是上行寬帶？是因?yàn)橹挥猩闲袑拵В前褦?shù)據(jù)從本地推到一個(gè)服務(wù)器上云服務(wù)器，如果說上行寬帶不行，那么就會(huì)造成直播卡頓、掉幀以及說延遲。

這個(gè)時(shí)候就要去聯(lián)系寬帶運(yùn)營(yíng)商，去升級(jí)上行寬帶。大家這個(gè)時(shí)候要注意，不是下載速度，是上行寬帶。大家記住了嗎？