Tiktok直播最重要的時還是網絡，網絡不純凈，卡頓，延時大，系統是不會推薦的
用一下OgLive直播間，線路穩定，低延時不卡頓
Tiktok是什么，適不適合做？
TikTok其實就是海外版的抖音，而且是3年前的抖音，其核心玩法與產品邏輯，和我們熟悉的抖音都基本相似。
正因為TikTok和抖音的相似性，給了我們很多想象和可操作的機會。
抖音的各種運營策略和商業模式不斷被研究出來。而這些策略和模式，對于TikTok，也同樣適用。
不管是流量，還是變現，短視頻（抖音/TikTok）不斷展示出其產品模式該有的優越性和霸氣。
當新的機會出現時，你會猶豫，這會不會不適合我？
但你忽視了“新”也意味著，所有人都是第一次接觸，都處于同一起跑線。大家都是平等的。
此時，相對來說，越早進入這個領域的人，越有先發優勢，錯過了3年前的抖音，難道還要錯過TikTok第一波市場紅利嗎？互聯網入口和用戶注意力的遷移，正帶來海量低成本精準流量。
運營TikTok需要哪些準備？
我們發現，TikTok的下載和注冊往往就可以難倒80%的外貿人，有了充分的基礎準備，后續自然就會簡單很多，比如：
step1: 前期準備
一部單獨的運營手機（建議蘋果6以上）
一個海外的APPLEID賬號（注冊一個新海外ID）
一張海外手機卡（無卡：手機偽裝100%真實）
有出海線路（梯子）
需要Gmail郵箱（前期不建議用其他社媒賬號綁定）
Step2：如何安裝（以蘋果手機為例）
重置手機
手機初始化：根據目標市場和海外通道出口IP地址，選擇對應信息匹配設定，如：國家、區域、語言、時區、輸入法等
重置廣告識別碼
不要裝國內APP
TikTok有哪些變現玩法？1. 可以展示自己的產品，讓客戶聯系到你，或者獲取到客戶的聯系方式，做傳統外貿生意。
2. 可以電商帶貨，現在TikTok已經開通小黃車功能了，可以在視頻中添加跳轉到Shopify和Teespring的鏈接，直接就可以帶產品。
3. 接廣告，粉絲多了，就有廣告需求，比如：使用廣告主指定的音樂做背景，或是廣告主要求上傳或拍攝一個帶品牌露出的作品。
……
TikTok新功能發布01 美國區域dou+上線
TikTok美區開放了dou+功能，目前只有部分用戶有開通dou+的功能，dou+仍然屬于內測階段。
目前并不是對所有人開放。美區dou+功能的開通，意味著TikTok商業化進程又向前邁出一大步。
02視頻合輯 功能開通
TikTok在3月下旬開始和部分創作者合作，推出一項播放列表新功能——視頻合輯，創作者能通過合輯功能將自己TikTok賬號內的視頻按不同主題自行分類，分為若干合輯。
用戶根據自己的需要和喜好對合輯命名，在創建合輯后，選中的視頻就會出現在創作者的個人資料下方，方便粉絲查找和觀看。
合輯功能的推出，有助于幫助創作者提高TikTok視頻的曝光率和互動率，連載性質的視頻內容，上一個視頻播放完自動切入下一個視頻。延長觀眾的參與時間，增強用戶黏度，有利于建立更牢固的聯系。
03 無人直播
無人直播是指非實時直播，是通過技術手段播放短視頻來代替直播推流。無人直播本質上不是直播而是一段通過剪輯合成的視頻，所以無人直播只要被官方發現，就難逃被封禁的命運。
然而TikTok平臺官方對于無人直播的管控并不嚴格，無人直播只要做好賬號粉絲數量，選好品，再配合針對性的直播素材，可以實現很不錯的佛系出單模式。
無人直播邊際成本極低，人力成本也不高，因此當下把握住TikTok疏于管控的風口更為重要。
04 新增特效功能 畫面逼真
不愿錯過短視頻機會的你，趕緊行動起來吧！
抖音直播有回音的解決方法如下：
1、檢查耳機與手機或電腦等設備連接是否正常，如果松動或沒有接好會出現電流引起的雜音。
2、設備卡頓造成直播軟件無法正常運行引起的雜音。
3、周圍有較強的干擾源引起的雜音，將其它的手機或電腦設備搬離。
4、抖音直播需要將給出的推流地址復制到串流軟件中，若推流地址錯誤會導致直播出現問題，重新復制推流地址填入串流軟件中。
短視頻運營實時更新
鏈接：買粉絲s://pan..買粉絲/s/1ceM1UDY9P8K13t68BdIyYA ?pwd=2D72
提取碼：2D72
資源包含：短視頻帶貨好物分享實操、剪映教程完整版 5980大藍線下課 陳廠長最新全套課 短視頻拍攝穩定器課程 抖音解封話術 抖音小店低成本引流500單總結 快手短視頻爆粉變現 零基礎學航拍 2022開課吧透透糖：短視頻帶貨爆單實戰營 修龍抖音房產 零基礎短視頻運營策劃教程 張sir豆莢運營 .莽哥·餐飲實體店引流課程 孫曉迪職業導演核心課 群響 IP06期 短視頻編導先導課（文案公式+三個表格推導） 朋友圈收費138元的抖音最新搬運技術 抖音變現+抖音新項目+信息換金術，三套合集【無水印】 【安心】口播入門與技巧課—從小白到高手 有了表現力咋拍都能火的短視頻表演課 七天陪跑系統實戰課【完結】 從0開始學習劇本殺 等
背景介紹：本人原先是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退到后臺，再回到前臺。


以上就是第二鐘情況。