tiktok怎样有点卡,tiktok推荐刷不出来
tiktok直播时候网卡是怎样回事
TIKTOK直播卡怎样解决?账号限流怎样解决?
1、弃号重做
如果这个被限流的账号没做多久,然后也修改了视频内容,音乐,进行了剪辑,依然没有起色的话,建议直接弃号,重新注册一个新的账号做起。根据以往的血泪教训,一个新账号被限流后解救的时间和精力远远大于重新起一个新号的本钱。
2、删除或隐藏foryou低的视频
你可以仔细检查下你做的账号,它是从哪一个视频开始没有foryou流量的,把从那个视频开始到最后发的没有foryou或foryou比例很低的视频都统统删除。
3、提升视频质量
原创的视频和高质量的视频是遭到广大用户的欢迎的,因此与其担心账号的版权或流量问题,还不如请专业的人员将账号视频做精做出自己的风格。
4、更换IP
TikTok重选问题,第一个检查的就是节点,而且70%以上的问题都是节点酿成的。
如果肯定是网络问题,可以试试TikTok原生IP。我们的企业SD-WAN专线可提供多个全球原生IP,除原生IP外还提供全球网络优化服务、国外专线、网络加速方案,覆盖(包括但不限于)国外游戏、跨国视频会议、跨境电商、国外直播等行业。
新平板刷抖音卡顿?
有几种可能
一种就是你家的网络带宽不行,看看用手机看会不会卡顿(只用无线网络,不用开手机网络),做一个对照,看看会不会是网络的缘由。
另外一种可能就是平板虽然是新的,但是本身的配置太低致使的卡顿。
还有一种就是配置没有问题,但是跟电脑一样需要下载相应的插件。
tiktok为啥卡顿,常常显示没有网络?
由于TikTok屏蔽了国内运营商Sim卡,经测试正规网络没法连接,取出Sim卡后可以连接使用。
最新2.0.8版会获得手机系统语言,简体中文系统没法连接,用繁体或英文系统,tiktok内容推荐就会只推荐繁体及英文内容。其实不是很建议大家使用国外版本的,由于网络很卡看视频不是很流畅,而且也没甚么新鲜的内容可看的,还不如看看国内的短视频。
网友爱好tiktok的理由:
1、居家隔离致使了人们将眼光转向短视频这个触手可及的文娱方式。受新冠疫情影响,隔离在家的人们如今具有了大把空闲时间。当家长们想了解孩子都在网上玩甚么时,也渴望参与进去。现在,愈来愈多的家庭都会一起玩TikTok,共同学习一段舞蹈或拍一段视频教程。
2、TikTok作为一个内容平台,正展现出愈来愈积极的一面。在如今的社交媒体平台上,网络霸凌几近无处不在。作为一个新兴的社交媒体,TikTok一直鼓励人们创作积极向上的内容。
TikTok发起了许多正能量的热门标签话题,比如保持宅家保持健康、跨性别日、赞美医生等。这些热门话题下有许多精彩内容,给人们带来欢乐和希望。
电脑抖音直播卡顿怎样解决?
咨询记录 · 回答于2022-04⑵5 电脑抖音直播卡顿怎样解决 解决方法以下:1、直接找抖音客服反应用电脑开抖音直播卡这个问题,客服会根据实际情况,告知你调试方法。2、电脑本身问题:电脑CPU性能不行。直播的话,最少4核CPU 主频3.4起步。如果要1K的分辨率 需要更高的CPU性能。
怎样在切入切出虚拟摄像头时营建卡顿效果
背景介绍:本人本来是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它,发现每次出错时,这个函数的毛病码都会报⑷21毛病(截图省略⑷21毛病码的测试进程)。


毛病信息非常明确的告知我们是由于相机不支持缩放,致使的打开相机失败,那末至此相机卡住的直接缘由找到了,但是还没找到为何特殊的操作流程后会卡住,而正常的操作不会。因而乎继续随着堆栈信息往上找。

发现走进了这里的流程,致使的相机进缩放流程,为了验证料想,我决定在这个函数调用前,把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函数里(也就是我们之前抛⑷21毛病堆栈的函数)。如果熟习相机开发的同学应当知道,一般我们界面退到后台会释放相机,然后回到前台重新打开。那末接下来我们把这几个函数都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,相机正常,紧接着我们发现了⑷21毛病,发现又重走了父类的onStart函数,那末此时status或者1。

接下来切换相机画面卡住了,但或者走了父类的onStart。


以上就是第一种情况,由于每次切换相机都会抛完⑷21毛病后,再调用父类ExternalVideoCapturer的start函数来重置status,也就造成了能调用Camera.open但是画面卡住的情况。
•情况二:先滑动界面,再切换相机,然后按home键,接着回到tiktok,最后切换相机,此时status()函数返回2,没走后续Camera.open流程。
前面流程就不贴了,直接开后面的流程记录。
退到后台 status=1

回到前台status=1

切换相机第一次,画面正常status=1

切换相机第二次,在调用switchCamera之前先抛了一次⑷21的毛病,致使status=2,然后switchCamera函数里判断status为2就被return,没有调用Camera.open函数,接下来也没有更多函数来重置status的状态,所以不管怎样切换相机,都没法履行到Camera.open(),除非tiktok退到后台,再回到前台。


以上就是第二钟情况。