02 tiktok出錯了怎么解決(為什么芯片難造？)

nFrameAvailableListener后，相機的可用幀會回調到這個函數，切換相機后卡頓，可用幀也同時不回調。

接下來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退到后臺，再回到前臺。





以上就是第二鐘情況。

活動運營基本流程和核心要素

首先，對比傳統的制造業中國的移動互聯網產品出海的表現，顯然更加亮眼；其次，對比去年榜單，工具類APP的位置已被內容類APP取代，字節跳動憑借TikTok首次入圍就殺入前五的位置，表明中國移動互聯網出海進入內容型產品主導階段。

內容型產品的底層邏輯是內容生產——內容分發——內容消費(變現)。其中，內容生產是決定成敗的首要條件如何降低內容生產成本成為很多公司必須要面對的問題，在PGC內容生產成本居高不下的情況，只有在UGC內容生產上下功夫才能健康持續發展。特別是在如今移動互聯網出海進入內容型產品的主導階段，研究這個課題更具現實意義。

內容型產品的冷啟動，包括短視頻、網文等產品，除了團隊自制和授權合作等PGC手段，以及簽約KOL帶動UGC創作外，另外一種方式是，通過特定的主題活動策劃進行UGC內容征集。以短視頻APP為例，通過策劃主題視頻征集活動，比如美妝達人視頻征集大賽，旅游達人視頻征集大賽等，在社交媒體上推廣征集大賽的H5頁面進行短視頻UGC內容征集。

一來可以征集各類優質視頻，發掘優秀的短視頻達人，為產品上線進行內容儲備，實現內容冷啟動；其次通過在社交媒體推廣大賽可以為社交媒體主頁積累粉絲，為后續APP的推廣與品牌營銷做鋪墊。本文將通過復盤一個活動，來討論內容型產品出海如何通過活動實現UGC內容征集。文章基于實操案例，對部分內容和數據做了脫敏處理，但基本邏輯一致。該案例的剖析分為上下2篇，本文首先與大家分享“活動運營基本流程和核心要素”。

1、結合產品內容方向與用戶需求，明確活動的目標、資源和時間。

首先，活動策劃一定要在了解目標市場用戶需求，內容方向上有確定的規劃之后進行，因此負責活動運營的同學要與負責內容的同學進行充分溝通，以確定此次活動的主題。因為活動的根本目的是，通過特定內容主題活動推廣引導相關用戶進行內容生產，平臺可以對該主題優秀內容和創作者的快速征集和篩選，這兩點是核心要素，所以我們可結合現有資源(主要是獎品獎金和推廣

很赞哦!（25）