tiktok直播卡頓什么原因(電腦抖音直播卡頓怎么解決？)

tiktok為何卡頓，經常顯示沒有網絡？

因為TikTok屏蔽了國內運營商Sim卡，經測試科學上網無法連接，取出Sim卡后可以連接使用。

最新2.0.8版會獲取手機系統語言，簡體中文系統無法連接，用繁體或英文系統，tiktok內容推薦就會只推薦繁體及英文內容。其實不是很建議大家使用海外版本的，因為網絡很卡看視頻不是很流暢，而且也沒什么新鮮的內容可看的，還不如看看國內的短視頻。

網友喜愛tiktok的理由：

1、居家隔離導致了人們將目光轉向短視頻這個觸手可及的娛樂方式。受新冠疫情影響，隔離在家的人們如今擁有了大把空閑時間。當家長們想了解孩子都在網上玩什么時，也渴望參與進去。現在，越來越多的家庭都會一起玩TikTok，共同學習一段舞蹈或者拍一段視頻教程。

2、TikTok作為一個內容平臺，正展現出越來越積極的一面。在如今的社交媒體平臺上，網絡霸凌幾乎無處不在。作為一個新興的社交媒體，TikTok一直鼓勵人們創作積極向上的內容。

TikTok發起了許多正能量的熱門標簽話題，比如保持宅家保持健康、跨性別日、贊美醫生等。這些熱門話題下有許多精彩內容，給人們帶來歡樂和希望。

抖音直播很卡是什么原因

抖音直播很卡的原因有：

1、可能是網速太慢導致，可以切換網絡。

2、可能是手機性能太低，導致軟件運行卡頓，需要更換性能更強的手機。

抖音（TikTok）是由今日頭條推出的一款短視頻分享APP，于2016年9月上線，是一個專注于年輕人音樂短視頻創作分享的社區平臺。抖音應用人工智能技術為用戶創造多樣的玩法，用戶可以通過這款軟件選擇歌曲，拍攝音樂短視頻，形成自己的作品。抖音2016年9月上線，一直磨刀磨到今年春節后可能感覺跑通了才大舉壓上資源，產品優秀的數據表現又讓頭條很快決定將各種流量明星BD推廣資源全力導向這個可以提升公司品相的新項目。抖音很快成為頭條戰略級產品。當然，頭條最核心的算法優勢也用到了抖音上，一開始就在產品層面加入算法推薦模型保證內容分發效率。抖音的名字也改的也及時，如果還叫A.me可能大家都還不知道這是啥東西，直接把自己定位成年輕人的音樂短視頻社區就清楚多了。

電腦抖音直播卡頓怎么解決？

2、電腦本身問題：電腦CPU性能不行

直播的話，起碼4核CPU 主頻3

4起步

如果要1K的分辨率 需要更高的CPU性能

Tiktok直播運營為什么要用跨境專線？

TK買粉絲跨境專線一款市面上被眾多Tiktok跨境電商創業者所使用的的專業級Tiktok買粉絲，說它是TikTok運營中的必備工具，原因如下：

提高視頻播放速度：

TK買粉絲能夠加速TikTok視頻的加載速度，避免視頻卡頓，提高視頻播放質量，從而增加用戶觀看體驗，提升視頻曝光率和播放量。

突破地域限制：

TK買粉絲能夠突破地域限制，幫助用戶在全球范圍內觀看TikTok視頻，避免因地域限制導致視頻無法播放的問題，從而擴大視頻的受眾范圍，增加曝光量和流量。

提高賬號曝光率：

加速直播流暢度：

TK買粉絲不僅能夠加速TikTok視頻的加載速度，還能夠提高直播的流暢度，避免因網絡不穩定而導致的卡頓和斷流問題，從而提高直播的觀看體驗，增加直播的曝光率和流量。

綜上所述，TK買粉絲不僅是一款提供節點的Tiktok買粉絲，更是TikTok運營的必備工具，可以幫助用戶提高視頻播放質量，突破地域限制，增加曝光量和流量，提高賬號的曝光率，加速直播的流暢度，從而提升TikTok賬號的影響力和商業價值。

怎樣在切入切出虛擬攝像頭時營造卡頓效果

背景介紹：本人原先是android逆向工程師，后來因為工作變動，離開了協議分析這類的崗位，目前在做直播機與第三方應用兼容性分析相關分析，所以就有了這篇兼容性分析文章。

問題：tiktok在我們推流設備直播時，經過幾個特定步驟后切換前后置攝像頭會出現卡住的問題。

現象：直播畫面卡住不動了。

解決思路：找到點擊切換按鈕后的點擊事件回調，找到切換攝像頭的核心邏輯，來找到卡住原因。

1、如果了解ART虛擬機的同學會知道，jni函數和java函數都會調用到art虛擬機ArtMethod的Invoke函數。



輸出日志：

find target method: android.view.View.performClick

ArtMethod Invoke【22955】: ; lr:0x4af78c; libart.so: android.view.View.performClick

ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: java.lang.Enum.toString

ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: X.Ggh.LIZ

ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: java.util.LinkedHashMap.<init>

ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: java.util.HashMap.putAll

ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: java.util.HashMap.put

ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: X.DED.LIZ

ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: X.D5k.onClick

通過frida hook libart.so的ArtMethod的Invoke函數，我們找到了點擊事件的回調類X.D5k.



找到這個類對應的onClick函數后，我對整個流程做個簡單的研讀，感覺發現了核心代碼在注釋直播流處理。



跟著核心代碼一路往下找到LiveCore這應該就是直播的核心代碼，其實現類為LiveCoreImpl，ILiveStream的實現類為LiveStream。





發現此處只是做了日志信息的合成和應用鏡像之類的代碼，但是又找到一個核心的類LiveStreamVideoCapture。



追蹤到這里發現鏈路斷了，又湊巧通過frida打開tiktok卡死在啟動頁上，那么接下來使用Xposed繼續理流程。

上面的代碼雖然沒有追中到切換攝像頭的核心邏輯，但是我們找到了兩個核心邏輯的類LiveStreamVideoCapture和LiveCoreImpl，分別和直播視頻流控制直播核心流程控制相關，所以Xposed繼續走的時候以這兩個類為重點，那么此處就開始放大招了，hook這兩個類的所有函數，貼上代碼。注意這里使用的classloader是application的classloader。





日志太多了，這里通過shell命令setprop做了個日志控制。







然后找到CameraVideoCapturer類的tryDeliverFrame，這里是處理相機的視頻幀，感覺越來越接近真相了，繼續hook這個方法，然后發現相機切換卡住以后，這個方法也停止調用了，那么沒辦法，繼續往上找堆棧中run方法的調用調用處。



繼續hook。





找到這個類。



至此，熟悉相機開發的同學應該知道，這就是SurfaceTexture.setOnFrameAvailableListener后，相機的可用幀會回調到這個函數，切換相機后卡頓，可用幀也同時不回調。

接下來hook原生相機。







調用的是android.hardware.Camera，也就是camera1相關的api，切換卡頓的時候并沒有調用Camera.open函數。





首次開直播的時候調用了這兩個函數，點擊切換相機的時候并沒有調用，在X.HCF這個類里找到switchCamera函數，那么猜測首次開相機，和切換前后相機走的并不是同一個流程，因為這個bug只有在切換相機時才會出現，所以我們就不關注首次開相機的流程。





果然，切換相機的時候走了這個流程，這是又發現了LiveStreamVideoCapture這個核心類，那么簡單進去看看SwitchCaptureRunnable這個有沒有被創建。





經過測試，發現這個類只會被創建一次，而run方法每次切換都會被調用，而且卡住的情況下也會被調用，那么結合上面Camera.open卡住時沒有調用，可以大膽的猜測中間過程某個條件不滿足被return了。根據堆棧信息繼續往下找幾個關鍵點。





發現CameraVideoCapture里也有切換相機的流程，切一步步往下走，能調用到上面我們hook過的X.HCF的switchCamera，那么我們就看看這里的switchCamera有沒有調用吧。

•情況一：先滑動直播界面，再按home鍵，然后回到tiktok，再切換相機，此時status()函數返回1，走了后續Camera.open流程。





•情況二：先滑動界面，再切換相機，然后按home鍵，接著回到tiktok，最后切換相機，此時status()函數返回2，沒走后續Camera.open流程。



從日志看switchCamera兩種情況都走了，再結合switchCamera的源碼看，源碼里的status()函數的返回值決定了是否繼續往下調用切換相機的流程，很遺憾的是，兩種情況都出現了，而且都會卡住（為什么兩個status值會不一樣呢，這里先留個坑，最后來填）。這可把我難住了！

就在這時腦子突然開竅，既然畫面卡住，那么必然有錯誤信息回調，果然一搜索CameraVideoCapture這個核心類有onError函數，毫不猶豫hook它，發現每次出錯時，這個函數的錯誤碼都會報-421錯誤（截圖省略-421錯誤碼的測試過程）。





錯誤信息非常明確的告訴我們是因為相機不支持縮放，導致的打開相機失敗，那么至此相機卡住的直接原因找到了，但是還沒找到為什么特殊的操作流程后會卡住，而正常的操作不會。于是乎繼續跟著堆棧信息往上找。



發現走進了這里的流程，導致的相機進縮放流程，為了驗證猜想，我決定在這個函數調用前，把message里的what字段改成2，讓它不走這個流程，來看看是不是就不會導致界面卡住，于是就有了下面這段代碼。



經過這一番篡改，果真隨便怎么折騰，直播界面都不會卡住了。那么我只要找到那里給handler發送的這個message就應該離真想很近了。





然后找這個handler的sendMessage相關切message的what字段賦值為1的函數。



然后我找到了它，這個函數還和縮放相關，那就八九不離十了。





按之前的堆棧繼續hook，發現卡住的時候這些方法確實都走了，而正常的時候是不走的，那么在X.Dvc的LIZ繼續用拋堆棧大法。

得到如下兩種堆棧：

•X.DCM接收到了touch事件，然后交由X.DCc這個類進行手勢判斷，發現是需要執行縮放的手勢，于是執行了相機的縮放功能（由于我們業務原因需要隱藏底部NavigationBar，在Window底部上劃會顯示NavigationBar，上劃的手勢同時觸發了控件的以為需要執行相機縮放），但是我們的虛擬攝像頭又不支持縮放，導致打開相機失敗，畫面就卡在了之前相機拿到的最后一幀。



X.DCc類



X.DCO的invoke方法



•點擊tiktok的切換相機Button，觸發進入相機的縮放，這里就和我們之前的點擊事件聯系上了，紅框部分就是補上了之前沒關注但是最重要的相機縮放功能判斷部分。





至此，我們已經把相機卡住的直接原因和根本原因都找到了，先手勢再點擊切換相機觸發了進入相機縮放功能判斷流程，由于我們的虛擬相機不支持縮放，導致打開相機失敗，卡在相機的最后一幀（也可能是黑屏）。所以只要交付給framework組開發人員，讓他們支持相機縮放相關功能就可以了。

接下來來填前面留下的坑，為什么退到后臺會導致status函數的返回值不一樣？

我們回到CameraVideoCapturer類，看看這個status()函數到底是個什么鬼！



發現他是父類ExternalVideoCapturer的函數，而且就是返回個字段，那再看看他那里進行了賦值。



通過AndroidStudio自帶的字段讀寫索引功能，很容易找到父類里的start、stop和release函數，以及自身的onErrorOnHandler函數里（也就是我們之前拋-421錯誤堆棧的函數）。如果熟悉相機開發的同學應該知道，一般我們界面退到后臺會釋放相機，然后回到前臺重新打開。那么接下來我們把這幾個函數都hook一下，來驗證猜想。



這里我多hook了一個onCaptureStarted函數，這個函數會調用父類的onStart函數，想看看是否會有調了onCaptureStarted但是沒調父類的onStart的情況。然后還hook了CameraVideoCapturer自身重寫的onStart和父類ExternalVideoCapturer的onStart函數。

下面是剛打開直播時的日志，此時status=1。



•情況一：先滑動直播界面，再按home鍵，然后回到tiktok，再切換相機，此時status()函數返回1，走了后續Camera.open流程。

這是直播退到后臺時的調用，說明確實釋放掉了，但是又調用了父類的onStart函數，那么此時的應該為2的status又變回了1。



接下來回到前臺，此時一切正常status還是為1，而且重走了自身的onStart函數，相當于相機整個流程完全重開。



再接著切換相機第一次，這時的status還是為1，相機正常，緊接著我們發現了-421錯誤，發現又重走了父類的onStart函數，那么此時status還是1。



接下來切換相機畫面卡住了，但還是走了父類的onStart。





以上就是第一種情況，由于每次切換相機都會拋完-421錯誤后，再調用父類ExternalVideoCapturer的start函數來重置status，也就造成了能調用Camera.open但是畫面卡住的情況。

•情況二：先滑動界面，再切換相機，然后按home鍵，接著回到tiktok，最后切換相機，此時status()函數返回2，沒走后續Camera.open流程。

前面流程就不貼了，直接開后面的流程記錄。

退到后臺 status=1



回到前臺status=1



切換相機第一次，畫面正常status=1



切換相機第二次，在調用switchCamera之前先拋了一次-421的錯誤，導致status=2，然后switchCamera函數里判斷status為2就被return，沒有調用Camera.open函數，接下來也沒有更多函數來重置status的狀態，所以無論怎么切換相機，都無法執行到Camera.open(),除非tiktok退到后臺，再回到前臺。





以上就是第二鐘情況。

很赞哦!（19717）