本文主要介紹如何調(diào)整宇都 的合伙人 s直播有點(diǎn)低(宇都 相關(guān)的合作伙伴)，下面一起看看如何調(diào)整宇都 的合伙人 s直播有點(diǎn)低(宇都 相關(guān)的合作伙伴)相關(guān)資訊。
希望這篇文章能讓你對卡頓這個問題有一個相對整體的看法，認(rèn)識到什么是卡頓，卡頓產(chǎn)生的原因，卡頓的分類，卡頓的優(yōu)化以及一些經(jīng)驗(yàn)積累，從而有針對性的解決app流暢問題。接下來將從以下五個方面進(jìn)行闡述:
卡頓是什么？
卡頓為什么會發(fā)生？
如何評價(jià)卡頓
如何優(yōu)化卡頓
加入我們
1.卡頓卡頓是什么？顧名思義，用戶 s體感接口不流暢。我們知道手機(jī)的屏幕圖像是以一定的頻率刷新的。理論上24幀的屏幕更新可以讓人感覺連貫。但其實(shí)這只是針對普通視頻。對于一些互動性強(qiáng)或者比較敏感的場景，比如游戲，至少需要60幀，30幀的游戲會讓人感覺不舒服；位移或者30幀的大尺度動畫會有明顯的頓挫感；如果手辦動畫能達(dá)到90幀甚至120幀，會讓人覺得很細(xì)膩，這也是最近廠商重點(diǎn)關(guān)注高刷卡的原因。
對于用戶來說，從體感的角度來看，卡頓大致可以分為以下幾類:
這些體驗(yàn)對用戶來說可以說是非常不好的，甚至?xí)斐筛泄偕系臒┰?，進(jìn)而導(dǎo)致用戶不愿意在我們的app停留?？梢哉f流暢的體驗(yàn)對用戶來說是非常重要的。
2.用戶 s體感卡頓問題發(fā)生，往往是復(fù)合問題。為了重點(diǎn)，我們暫時只考慮真正的丟幀卡在這里。
2.1 vsync，可以 不可避免，我們通常說的屏幕刷新率是60幀，所有操作都需要在16ms內(nèi)完成，避免卡頓。但這里有幾個基本問題需要澄清:
為什么是16ms？你需要在16毫秒內(nèi)完成什么？系統(tǒng)如何盡力保證在16ms內(nèi)完成任務(wù)？如果沒有在16ms內(nèi)完成，一定會造成卡頓嗎？讓 讓我們在這里回答第一個問題:為什么是16ms？早期的android沒有vsync機(jī)制，cpu和gpu的配合也比較混亂，這也造成了著名的撕裂問題，即cpu/gpu直接更新正在顯示的屏幕緩沖區(qū)，導(dǎo)致畫面撕裂。后續(xù)的android引入了雙緩沖機(jī)制，但是緩沖的切換也需要一個更合適的時間，就是屏幕掃描完最后一幀之后的時間，這也是引入vsync的原因。
以前一般的屏幕刷新率是60fps，所以每個vsync信號的間隔是16 ms，但是隨著技術(shù)的變化和廠商對流暢度的追求，越來越多的90fps和120fps的手機(jī)問世，相應(yīng)的間隔變成了11ms和。8毫秒.
現(xiàn)在有了vsync，誰在消費(fèi)vsync？實(shí)際上，android中的vsync有兩個消費(fèi)者，對應(yīng)兩種類型的vsync信號，即vsyncapp和vsyncsf，也對應(yīng)上層視圖繪制和surfaceflinger的合成。具體我們接下來會詳細(xì)說。
這里有一些有趣的地方。有些廠商會有vsync偏移的設(shè)計(jì)，app和sf的vsync信號之間存在偏移，這也在一定程度上使得app和sf的協(xié)更好。
2.2查看和查看。;■流浪生活在談下一部分之前，引入一個話題:
屏幕上究竟是如何顯示視圖的？
我們一般比較了解視圖渲染的三個過程，但是視圖的渲染遠(yuǎn)不止這些:
在這里，它的特點(diǎn)是一個通用的硬件加速過程。
vsync調(diào)度:很多同學(xué)的一個認(rèn)知誤區(qū)是，每16ms就會有vsync，但其實(shí)vsync是需要調(diào)度的，沒有調(diào)度就不會有回調(diào)；消息調(diào)度:主要是doframe的消息調(diào)度。如果消息被屏蔽，會直接造成堵塞；輸入處理:觸摸事件的處理；動畫處理:動畫師動畫執(zhí)行和渲染；視圖處理:主要是視圖相關(guān)的遍歷和三大流程；實(shí)現(xiàn)三大流程:測量、布局和繪圖:視圖；顯示列表更新:查看硬件加速后的drawopopengl指令轉(zhuǎn)換:將繪圖指令轉(zhuǎn)換成opengl指令；指令緩沖交換:opengl指令交換到gpu執(zhí)行；gpu處理:gpu對數(shù)據(jù)的處理過程；層合成:表面緩沖合成屏幕顯示緩沖的過程；柵格化:矢量圖轉(zhuǎn)換成位圖；顯示:顯示控制；緩沖區(qū)切換:切換屏幕顯示的幀緩沖區(qū)；google將這個過程分為:其他時間/vsync延遲、輸入處理、動畫、測量/布局、繪圖、同步和上傳、命令問題、交換緩沖區(qū)。也就是我們常用的gpu嚴(yán)格模式，其實(shí)道理是一樣的。至此，我們已經(jīng)回答了第二個問題:16ms需要完成什么？
準(zhǔn)確來說，這里還可以進(jìn)一步細(xì)化:app端數(shù)據(jù)的制作在16ms內(nèi)完成；在16 ms內(nèi)完成sf層的合成
視圖的視覺效果是通過這整個復(fù)雜的環(huán)節(jié)一步步展現(xiàn)出來的。有了這個前提，就可以斷定以上任何一個環(huán)節(jié)都會卡死。
2.3生產(chǎn)者和消費(fèi)者讓 讓我們回到垂直同步的話題。消費(fèi)vsync的兩方是app和sf，其中app代表生產(chǎn)者，sf代表消費(fèi)者，他們交付的中間產(chǎn)品是surface buffer。
更具體的說，生產(chǎn)者大致可以分為兩類，一類是以window為代表的頁面，也就是我們平時看到的視圖樹；另一類是以視頻流為代表的可以直接與surface交換數(shù)據(jù)的源，比如攝像頭預(yù)覽。
對于一般的生產(chǎn)者和消費(fèi)者模型，我們知道會有相互阻斷的問題。比如生產(chǎn)者快而消費(fèi)者慢，或者生產(chǎn)者慢而消費(fèi)者快，那么整體速度就會慢，資源就會浪費(fèi)。所以體現(xiàn)了vsync的協(xié)和雙緩沖甚至三緩沖的作用。
思考一個問題:緩沖區(qū)越多越好嗎？什么？;過多緩沖的問題是什么？答案是會造成另一個嚴(yán)重的問題:滯后，響應(yīng)延遲。
在這里結(jié)合生活觀，我們可以把這兩個過程結(jié)合起來，使我們的視角更高:
2.4機(jī)制保護(hù)在這里，讓 讓我們來回答第三個問題。從系統(tǒng)的渲染架構(gòu)來看，機(jī)制保護(hù)主要包括幾個方面:
vsync機(jī)制的協(xié)作；多緩沖設(shè)計(jì)；表面的提供；同步屏障的保護(hù)；硬件繪圖支持；支持渲染線程；gpu合成加速；這些機(jī)制的保護(hù)在系統(tǒng)層面最大程度上保證了app體驗(yàn)的流暢性，但是它可以 不能幫助我們徹底解決停滯的問題。為了提供更流暢的體驗(yàn)，一方面可以加強(qiáng)系統(tǒng)的機(jī)制保護(hù)，比如fwatchdog；另一方面，需要從app的角度出發(fā)，管理應(yīng)用中的卡頓問題。
2.5看看堵塞的原因經(jīng)過上面的討論，我們得到了堵塞分析的一個核心理論支持:渲染機(jī)制中任何異常的流量過程都會引起堵塞。
那么，讓我們 讓我們逐一分析一下，看看是什么原因造成了堵塞。
2.5.1渲染進(jìn)程的vsync調(diào)度:這是起點(diǎn)，但是調(diào)度進(jìn)程會經(jīng)過線程切換和一些委托邏輯，可能會造成卡殼，但是一般可能性比較小，我們幾乎無法介入；消息調(diào)度:主要是多幀消息的調(diào)度，屬于普通的handler調(diào)度。如果此調(diào)度被其他消息阻塞，將直接導(dǎo)致所有后續(xù)流程無法觸發(fā)。這里直播建立了一個fwtachdog機(jī)制，可以通過優(yōu)化消息調(diào)度達(dá)到插幀的效果，這樣，界面更流暢；輸入處理:輸入是vsync調(diào)度中執(zhí)行的第一個邏輯，主要處理輸入事件。如果有大量的事件堆積或者在事件分發(fā)邏輯中加入大量耗時的業(yè)務(wù)邏輯，那么當(dāng)前幀的時長會被放大，導(dǎo)致卡頓。tik tok基礎(chǔ)技術(shù)專業(yè)學(xué)生也嘗試了事件抽樣方案，減少了對事件的處理，取得了良好的效果；動畫處理:主要是動畫師的動畫更新。同樣，動畫太多，或者動畫更新存在耗時的邏輯，也會導(dǎo)致當(dāng)前幀的渲染卡頓。這個問題其實(shí)是通過降低動畫的幀數(shù)和復(fù)雜度來解決的；視圖處理:主要是下三個流程。過度繪制、頻繁刷新和復(fù)雜的視圖效果是這里卡頓的主要原因。比如我們通常所說的降低頁面級別，主要就是解決這個問題；measure/layout/draw:視圖渲染的三大流程涉及遍歷和高頻執(zhí)行，所以這里涉及的耗時問題會被放大，比如we can 不要在draw，can t新對象，等等；displaylist的更新:這里主要是canvas和displaylist的映射。一般不會出現(xiàn)卡頓問題，但可能會出現(xiàn)映射失敗導(dǎo)致的顯示問題；opengl指令轉(zhuǎn)換:這里主要是把canvas的命令轉(zhuǎn)換成opengl的命令，一般沒有問題。但是，這里有一點(diǎn)可以探討。會不會有一種特殊的canvas指令，轉(zhuǎn)換后的opengl指令消耗很大，導(dǎo)致gpu的損耗？有知識的同學(xué)可以討論一下；緩沖區(qū)交換:這個主要是指opengl指令集到gpu的交換，一般和指令的復(fù)雜程度有關(guān)。一個有意思的事情是，它曾經(jīng)作為在線采集gpu指標(biāo)的數(shù)據(jù)源，但由于多重緩沖因素導(dǎo)致數(shù)據(jù)準(zhǔn)確性不足而被放棄；gpu處理:顧名思義，這是gpu對數(shù)據(jù)的處理，耗時主要與工作量和紋理復(fù)雜度有關(guān)。這就是為什么我們可以減少gpu負(fù)載來幫助減少堵塞；圖層合成:這主要是圖層合成的工作，一般是不可訪問的。偶爾會發(fā)現(xiàn)sf s vsync信號延遲，導(dǎo)致緩沖不能及時供給，原因暫時不清楚；光柵化/顯示:這里暫時忽略底層系統(tǒng)的行為；緩沖區(qū)切換:主要是屏幕的顯示，這里緩沖區(qū)的多少也會影響幀的整體延遲，但這是系統(tǒng)行為，不能干涉。2.5.2視頻流不僅僅是上述渲染過程造成的。卡頓，還有一些其他因素，典型的就是視頻流。
渲染卡頓:主要是textureview渲染，textureview和window共用一個面，每一幀都需要一起渲染，互相影響。ui卡頓會造成視頻流卡頓，視頻流卡頓有時會造成ui卡頓；解碼:解碼主要是將數(shù)據(jù)流解碼成surface可消耗的緩沖數(shù)據(jù)，這是除了網(wǎng)絡(luò)之外最重要的耗時點(diǎn)?，F(xiàn)在我們一般都是用硬件解碼，比軟的解決方案好很多。但是幀的復(fù)雜度，編碼算法的復(fù)雜度和分辨率也會直接導(dǎo)致解碼時間的拉長。opengl處理:有時候解碼后的數(shù)據(jù)會被處理兩次，耗時的話會直接導(dǎo)致渲染卡頓；網(wǎng)絡(luò):我贏了 這個就不贅述了，包括dns節(jié)點(diǎn)優(yōu)化，cdn服務(wù)，gop配置等。推流異常:這屬于數(shù)據(jù)源的問題，所以我們將重點(diǎn)放在用戶 暫時不討論這個問題。系統(tǒng)負(fù)載
內(nèi)存:內(nèi)存不足會直接導(dǎo)致gc甚至anr的增加，這是一個不可忽視的因素；cpu:cpu對卡頓的影響主要在于幀率以vsync的到達(dá)時間為起點(diǎn)，doframe s完成作為終點(diǎn)，這是每一幀的渲染時間。同時，利用渲染時間/刷新率可以得到每次渲染丟失的幀數(shù)。平均fps =一段時間內(nèi)渲染幀數(shù)* 60/(渲染幀數(shù)，丟失幀數(shù))
垂直同步
暫停_視頻_用戶界面_速率
總滯留率
(ui捕捉持續(xù)時間、流捕捉持續(xù)時間)/采集持續(xù)時間
垂直同步
停止_用戶界面_速率
用戶界面停滯率
[3幀] ui停滯持續(xù)時間/采集持續(xù)時間
垂直同步
暫停_視頻_速率
流量計(jì)費(fèi)率
流動堵塞持續(xù)時間/采集持續(xù)時間
垂直同步
stall _ ui _ slight _ rate
輕微卡住率
[36]幀丟失時長/采集時長
垂直同步
stall _ ui _ medium _ rate
中等滯留率
[713]幀丟失時長/采集時長
垂直同步
失速_ ui _嚴(yán)重_速率
嚴(yán)重卡住率
[14]幀丟失時間/采集時間
垂直同步
3.2離線指示器diggo是bytes開發(fā)的開放式開發(fā)調(diào)試工具平臺，是集 評估、分析和調(diào)試。內(nèi)置性能評測、界面分析、卡頓分析、內(nèi)存分析、崩潰分析、實(shí)時調(diào)試等基礎(chǔ)分析能力，可為產(chǎn)品開發(fā)階段提供有力幫助。
指數(shù)
意譯
計(jì)算
數(shù)據(jù)源
每秒傳輸幀數(shù)
機(jī)會渲染幀速率
數(shù)據(jù)采集時間段中的實(shí)際渲染幀/數(shù)據(jù)采集間隔。
sf gfxinfo
rfps
相對幀速率
在數(shù)據(jù)采集時間段內(nèi)，(理論全幀實(shí)際丟幀)/數(shù)據(jù)采集間隔
gfxinfo
口吃
卡頓率
卡頓比。jank發(fā)生時，幀的累計(jì)持續(xù)時間與間隔持續(xù)時間的比率。
芬蘭
揚(yáng)基計(jì)數(shù)
普通滯留時間
當(dāng)單幀的繪制時間長于movie_frame_time時，janky計(jì)一次。
芬蘭
大詹基伯爵
嚴(yán)重卡住時間
單幀畫圖時間超過3*movie_frame_time時，算大janky一次。
芬蘭
4.如何優(yōu)化卡頓4.1.1在線工具名稱中常用的工具？
意譯
形式包慢函數(shù)
與灰度包相比，過濾更多監(jiān)控，性能損失更小，但需要手動打開，單點(diǎn)反饋不能預(yù)留反饋位。
灰色包慢速功能
灰度上開啟全量，對于版本間的數(shù)據(jù)對比和解決新卡頓問題更有效。
anr
anr的及時反應(yīng)和處理
4.1.2離線工具的工具名稱
評論
系統(tǒng)跟蹤
我贏了。;暫時不要談細(xì)節(jié)
佩爾費(fèi)托
systrace的增強(qiáng)版，可定制，可以參考官方文檔。
瑞亞
最常用最好的工具就是方便找到下一個問題和歸屬。和perfetto是絕配。有興趣的同學(xué)可以去github搜一下btrace。
仿形銑床
androidstudio自帶工具，方便，但是數(shù)據(jù)精度不高。
sf / gfxinfo
主要用于腳本和工具。
4.2這里常見的思路主要是針對ui和ui/流交互的停滯。
對于ui卡頓，我們是無敵的卡頓 優(yōu)化的8板axe:
離線代碼；減少處決數(shù)量；異步；分手；預(yù)熱；多路復(fù)用；方案優(yōu)化；硬件加速；總的想法是 唐 能不做就不做，能少做就少做，能早做就早做，能晚做就晚做，能讓別人做就讓別人做，能做10次就只做一次。如果它 實(shí)在不行，那就考慮自己做。
以下是一些常見的優(yōu)化思路。注意，這一定不是全部。如果有其他好的優(yōu)化思路，可以一起交流。
4.3已經(jīng)做的一些事情4.3.1解決ui堵塞直播造成的流量堵塞是surfaceview切換的一個長期專項(xiàng)，分多個階段逐步落地直播。場景涵蓋秀場直播、聊天室、游戲直播、電商直播、媒體直播等。，并且在業(yè)務(wù)滲透率和停留時間方面有比較。顯著的好處，同時功耗的好處也相當(dāng)可觀。
這里有一個取舍問題，surfaceview的兼容性問題pk帶來的收益能否拉平。一般來說，業(yè)務(wù)場景越復(fù)雜，收益越大。
4.3.2消息調(diào)度fwatchdog的解決方案基于messagequeue的調(diào)度策略和同步屏障原理，以平均幀時間為閾值判斷丟幀后主動將同步屏障插入messagequeue，以保證渲染異步消息和多幀的優(yōu)先執(zhí)行，達(dá)到渲染插入幀的效果，同時具備anr自動恢復(fù)同步屏障的能力，保證分手的有效性。
所以fwatchdog和daisan是很好的搭檔，可以產(chǎn)生1 1大于2的效果。
4.3.3減少執(zhí)行次數(shù)一個典型的應(yīng)用場景是滑動場景的gc抑制，它可以顯著提高用戶 大起大落的經(jīng)歷。這個場景相信每個業(yè)務(wù)都會存在，尤其是遍歷邏輯很多，優(yōu)化效果明顯。
4.3.4代碼離線一些舊的框架，沒用的邏輯，存在感低的代碼都可以離線。在這里，基本業(yè)務(wù)是強(qiáng)相關(guān)的，所以我贏了 我不能給出具體的例子。
4.3.5解決耗時函數(shù)(散點(diǎn)/異步)，第一步是散點(diǎn)。直播做了大量的任務(wù)拆分分散，可以減輕當(dāng)前渲染幀的耗時壓力，第二步可以結(jié)合fwatchdog實(shí)現(xiàn)插幀的效果。其實(shí)還可以控制任務(wù)執(zhí)行的優(yōu)先級，包括插隊(duì)等?？傊?，合理調(diào)度messagequeue是很有必要的。
異步的使用也相對較多。一個掩埋點(diǎn)日志的框架，以及一些inflate的加載，都可以使用異步來解決卡頓問題。
4.3.6預(yù)熱直播提供預(yù)熱框架，允許直播內(nèi)部的一次性開銷邏輯在主機(jī)端執(zhí)行，并提供完整的隊(duì)列優(yōu)先級管理、同步異步管理和任務(wù)生命周期管理，減少直播內(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ì)是一個集體驗(yàn)優(yōu)化、平臺搭建、跨端、端智能、穩(wěn)定于一體的綜合性團(tuán)隊(duì)。團(tuán)隊(duì)氛圍不錯，技術(shù)成長很快，有足夠的自由度發(fā)揮自己的特長，也面臨著更多樣的挑戰(zhàn)。每一行代碼都會讓億萬用戶體驗(yàn)更好！邀請你加入我們。對這些方向感興趣的同學(xué)可以過來聊聊。內(nèi)部鏈接是 鏈接 。
了解更多如何調(diào)整宇都 的合伙人 s直播有點(diǎn)低(宇都 相關(guān)的合作伙伴)相關(guān)內(nèi)容請關(guān)注本站點(diǎn)。