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-25电脑直播卡顿如何解决？ 1、把在电脑上打开抖音直播卡的问题直接反映给抖音客服，客服会根据实际情况教你如何调试。 2、电脑本身的问题:电脑的CPU性能不行。 直播的话，至少4核CPU的主频是3.4开始。 要求1K的分辨率需要更高的CPU性能。

怎样在切入切出虚拟摄像头时营造卡顿效果

背景介绍:本人原为android反向工程师，因工作变动退出了协议分析类岗位，目前正在进行直播机与第三方APP应用的兼容性分析，有此兼容性分析文章。

问题: tiktok在按下流媒体设备进行现场直播时，如果经过几个特定步骤在前后摄像机之间切换，就会出现卡涩的问题。

再现步骤:在实时界面中打开更多菜单→返回后台→返回前台→切换前后菜单。

现象:直播屏幕堵塞了，不能动了。

解决方案:找到点击切换按钮后点击事件的回调，找到切换摄像头的核心逻辑，找到卡住的原因。

1、如果知道ART虚拟机的同学会知道的话，jni函数和java函数两者都会调用ART虚拟机ArtM: Android.view.view.perform click

ArtM:； lr:0x4af78c； libart.so : Android.view.view.perform click

ArtM:； lr:0x2: Java.lang.:； lr:0x2: x.ggh.Liz

ArtM:； lr:0x2: Java.util.link:； lr:0x2: Java.util.hashmap.putall

ArtM:； lr:0x2: Java.util.hashmap.put

ArtM:； lr:0x2: x.d:； lr:0x2: x.d5k.onclick

使用frida hook libart.so的art method invoke函数找到了单击事件的回调类X.D5k。



找到与该类对应的onClick函数后，我感觉我简单研究了整个过程，发现核心代码在对直播流处理进行评论。



在核心代码之后寻找LiveCore，我想这就是live的核心代码。 其实现类为LiveCoreImpl，LiveStream的实现类为LiveStream。





这里只是编写了日志信息的合成和应用镜像等代码，但是找到了核心类LiveStreamVideoCapture。



跟踪到这里，发现链接已经断开，又在frida中打开tiktok卡，在启动页上死了，下次使用Xposed继续流程。

上面的代码赶不上切换摄像头的核心逻辑，但是找到了两个核心逻辑的LiveStreamVideoCapture类和LiveCoreImpl。 因为每个都与直播视频流控制直播核心流程控制相关，所以在Xposed持续的时候我们以这两个类为重点，在这里开始了扩招。 hook将代码粘贴到的所有函数中。 请注意，此处使用的类加载器是应用程序的类加载器。





日志太多了。 在这里用shell命令setprop进行了日志控制。







然后，找到CameraVideoCapturer类的tryDeliverFrame。 这里正在处理摄像机的视频帧。 感觉越来越接近了。 继续使用名为hook的方法。 然后，在卡在摄像机切换中之后，这个方法也停止了调用。 没办法，只能继续寻找堆栈中run方法的调用方。



继续hook。





找到这个班。



现在，熟悉照相机开发的学生应该知道这是surface texture.setonframeavailablelistener。 摄影机的可用帧回调到此函数，在切换摄影机后，摄影机将变为铁路超高，可用帧也不会同时回调。

接下来是hook原生摄像头。







调用的是android.hardware.Camera，即与camera1相关的api，在切换卡顿时没有调用Camera.open函数。





第一次开始实时时调用了这两个函数，但在单击“切换摄影机”时没有调用。 在名为X.HCF的类中找到switchCamera函数时，估计第一次打开摄像机时和切换前后摄像机所做的流程不同。 此错误仅在切换相机时出现，因此不关注首次打开相机时的流程。





果然，切换照相机的时候遵循了这个流程。 这又发现了一个名为LiveStreamVideoCapture的核心类。 那么我们就简单进去看看有没有制作出SwitchCaptur测试，我们发现这个类只被创建一次，每次切换run方法时都会被调用，如果被卡住的话也会被调用。 那么，结合上述Camera.open被卡住时没有被调用的情况，可以大胆推测中间进程的某个条件没有得到满足就被返回了。 根据堆栈信息继续寻找几个关键点。





我发现CameraVideoCapture也有切换照相机的流程。 一步一步往下，就可以调用上面的我们在hook过的X.HCF的switchCamera了。 那么，我们来看看这里的switchCamera是否被调用了。

情况1 )滑动实时界面，按home键，然后返回tiktok并切换摄像头。 此时，status ) )函数返回1，前往后续的Camera.open流程。





情况2 )滑动界面后切换摄像头，按home按键返回tiktok，最后切换摄像头。 此时，status ) )函数返回2，并且不再进入后续的Camera.open进程。



从日志上看switchCamera的话，两种情况都会去。 此外，如果结合switchCamera的源代码进行查看，则源代码中的status ) )函数的返回值将决定是否继续调用切换摄像机的过程。 很遗憾，两种情况都会发生，会被卡住。 (为什么两个status值不同呢？ 在这里留个洞，最后补上。 ) ) ) 652这让我为难了！

那时，脑子突然打开，既然画面堵塞了，就一定会有错误信息的回叫。 果然，当我搜索到名为CameraVideoCaptur测试进程





错误信息清楚地表明照相机无法打开，因为照相机不支持变焦。 那么，到目前为止已经找到了摄像头堵塞的直接原因，但为什么卡在特殊的操作流程之后，无法进行通常的操作还没有找到。 于是跟着堆栈信息继续向上找。



进入这里的流程，我发现了照相机进入变焦的流程。 为了验证预期，我们决定在调用此函数之前，将消息的what字段更改为2，以避免此流程，并检查接口是否堵塞。 因此，出现了以下代码。



经过这个篡改，就算真的被随意耍了，直播界面也不会挂科了。 只要在那里找到发给handler的这个消息，我就真的应该很接近。





然后，查找截断此handler的sendMessage相关消息的what字段赋值为1的函数。



然后我找到了那个。 这个函数也和缩放有关。 它离不开十。





按前面的堆栈继续hook，堵塞的时候这些方法确实都走了，正常的时候不走，那么在X.Dvc的LIZ上继续使用堆栈扔。

得到以下两种堆栈:

x.DCM接收到touch事件，将其传递给名为X.DCc的类进行手势判断，发现这是需要执行缩放的手势，然后执行相机的缩放功能。 (由于我们的业务原因，我觉得必须隐藏下面的导航栏，在窗口下方显示导航栏，控件需要在向上拉动的同时进行相机缩放。 ) )



X.DCc类



X.DCO的invoke方法



单击tiktok的切换摄影机Button触发了进入摄像机的变焦，在这里导致了我们以前的点击事件。 红框的部分是对之前没有注意到的、最重要的照相机变焦功能判断部分的补充。





到此为止，我们找到了摄像头堵塞的直接原因和根本原因。 做手势，然后点击切换摄像头，进入判断摄像头变焦功能的过程。 我们的虚拟摄像机不支持变焦，所以摄像机开机失败，卡在了摄像机的最后一个框架(可能是黑屏)上。 所以，交付给framework集团的开发者，让他们支持摄像机变焦的相关功能就可以了。

接下来填补前面剩下的洞。 为什么下降到背景时，status函数的返回值会不同呢？

回到CameraVideoCapturer类，看看这个status ( )函数是什么。



发现他在父类ExternalVideoCapturer的函数中返回字段。 那么，让我们看看在他那里进行了代入。



通过使用AndroidStudio提供的字段读写索引功能，可以使用父类的start、stop、release函数和自己的onErrorOnHandler函数(即抛出-421错误堆栈的函数) 熟悉摄像头开发的学生应该都知道，一般我们的界面下降到后台就会释放摄像头，然后回到前台重新打开。 现在，让我们将这些函数全部设置为hook，以验证预期。



在这里，hook了很多onCaptureStarted函数。 该函数调用父类的onStart函数，查看是否有调整了onCaptureStarted，但没有调整父类的onStart的情况。 然后，CameraVideoCapturer自己重写的onStart和父类ExternalVideoCapturer的onStart函数也做了hook。

以下是刚打开实时时的日志。 此时，状态= 1。



情况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

情况2 )首先滑动界面，然后切换摄像头，按home键，然后返回tiktok，最后切换摄像头。 此时，status ) )函数返回2，不再跟随Camera.open的流程。

不贴上之前的流程。 直接打开后面的进程记录。

后退到背景status=1



返回前台status=1



只有在切换摄像头后，屏幕才能正常显示状态= 1



第二次切换摄影机时，在调用switchCamera之前先抛出一次-421错误，使status=2。 然后，如果switchCamera函数确定status为2，则会返回，不调用Camera.open函数，也没有更多的函数重置status的状态





以上是第二个小时的情况。