今天给各位分享tiktok桌面截图的知识，其中也会对在抖音上不能双击截屏进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
海外媒体投放平台有哪些
海外媒体投放平台有以下
一、GoogleAdmob一般是海外投放首选的平台，主要是因为他拥有了众多媒体中最大最多的流量，并且Admob经过多年发展，拥有着成熟的精准投放后台，收到各类品牌商的青睐。
Google的广告形式除了我们比较熟悉的传统的Banner类广告以外，现在也在大力推行原生广告的合作，并且已经将广告形式拓展到视频广告领域，例如Youtube。GoogleAdmob广告投放业务固然发展成熟，但是由于长久以来的客户竞争，投放成本比较难以控制，比较适合需要快速增加大量曝光率的品牌商。
二、Facebook大家也比较熟悉，Facebook的广告后台是2010年刚上线的，当时被很多广告主指出问题，这是因为Facebook当时的广告后台非常不成熟，精准度也非常低，因此导致大量广告主投入了过高的投放成本。
但是，Facebook在经过几年的优化与改良后，凭借着庞大的用户群体以及非常完善的广告后台，Facebook已经成为众多海外PC和移动端最重要的广告投放平台之一了，很多选择海外投放的app都将Facebook当做广告投放中的重中之重，当然，也将更多的广告预算放进了Facebook的口袋。下面说一下Facebook的广告形式，目前Facebook可使用的广告形式包括链接广告、原生广告和pc端的传统广告等等。
三、选择HeroAPP原生广告进行投放，例如猎豹移动所推出的CleanMaster，这款app在以获得全球超2亿日活量用户的基础下，更加注重流量的变现化商业价值，在自己是非游戏类app应用的基础上，对其他的非游戏类app进行推广时也会得心应手，并且CleanMaster现在在自身app内开放了原生广告，这种非激励性的原生广告仅仅单日就为ZeroLauncher实现全球10万量级的流量分发，并且用户的留存率也很可观，并没有比Facebook的差。
四、Affiliate网盟是不错的海外广告投放媒体资源，Affiliate网盟的优势就是可以让广告主进行灵活的广告投放，并且有时用很低的成本就可以进行广告投放，但是Affiliate网盟由于在除了自身有接入各厂商的offer外，还将其他多家的网盟接入offer，这样就会有媒体质量不可控的隐患出现，需要谨慎投放。
五、Vine是Twitter旗下的一款短视频分享应用。在推出后不到8个月，注册用户数突破4000万。用用户可以通过它来发布长达6秒的短视频，并可添加一点文字说明，然后上传到网络进行分享。文芳阁建议企业可以通过这样的免费平台来进行360°全视角产品展示，或者发布一些有价值的品牌信息。
wallpaper超火的男人跳舞是哪
wallpape超火的男人跳舞指的是一段名为《TakeOnMe》的舞蹈视频，该视频拍摄于2019年，由两名舞者（其中一名为主角）在一个停车场内跳舞而成。这段视频在社交媒体上迅速走红，被大量转发和分享，并在短时间内获得了数百万的点击量。
主角的真实身份是一名来自美国的舞者叫做JoziahCouncil，他在视频中表现出了出色的舞蹈技巧和极具感染力的表演风格，吸引了大量的粉丝和关注者。许多人认为，他的舞蹈风格非常独特，能够将不同的舞蹈元素融合在一起，展现出极高的舞蹈水平和创意。
这段视频在社交媒体上的迅速传播，也反映了当下年轻人对于舞蹈和音乐的热爱和追求，以及网络传播对于文化艺术的影响和推广作用。同时，这个视频也成为了许多人的舞蹈学习和创作的灵感源泉，促进了舞蹈文化的传承和发展。
在抖音上不能双击截屏
记得几个月前，在抖音上红极一时的两指双敲的华为手机截屏，不需要任何设置操作，只需要将两个手指敲击屏幕两下，即可完成截屏，方便而又快捷。而苹果手机大家大多数知道的截屏方法，应该是分为第一种：home键加上音量键同时按，第二种：主界面中的屏幕快照。而这两种方法，说实话是有点麻烦的，一不小心就按成关机或者是点错要操作的内容，特别工作要用到截屏的时候，导致浪费时间。
事实上，苹果手机也可以完成双击屏幕进行截屏的操作，并且操作过程很简单易学的。操作过程被分为以下几步：首先我们可以打开【设置】这一项打开之后在设置界面往下翻找到【通用】一栏并点击打开接着继续通用界面往下翻打开【辅助功能】可以看到辅助功能的界面下有【辅助触控】，这一项需要把它打开打开后，在界面下面的自定义操作中选择【轻点两下】将它开启开启后，我们就要在在这里设置最后要实现的操作了，需要实现截屏功能的话，就需要在这个界面中找到【屏幕快照】，然后点击进行勾选就可以了。滚动截屏的方法：同时按下电源键和音量下键截取完整屏幕。截屏完成后，点击缩略图，然后点击滚动截屏按钮（或向下滑动缩略图）即可滚动截屏。滚动过程中，点击滚动区域可停止截屏。
如果手机无法滚动截屏，请您按照以下方法排查：
如下场景时，滚动截屏会自动停止
截屏高度超过限制（高度限制视情况而定，限制高度在14000像素左右）。滚动截屏过程中存在图片存储、读写文件等操作，并且截取的图片会占据内存空间。为了避免用户忘记主动停止滚动截屏，因此限定最大截屏高度，此高度一般能够保证长图的截取需求。
怎样在切入切出虚拟摄像头时营造卡顿效果
背景介绍：本人原先是android逆向工程师，后来因为工作变动，离开了协议分析这类的岗位，目前在做直播机与第三方应用兼容性分析相关分析，所以就有了这篇兼容性分析文章。
问题：tiktok在我们推流设备直播时，经过几个特定步骤后切换前后置摄像头会出现卡住的问题。
重现步骤：直播界面打开更多菜单->然后退到后台->回到前台->切换前后置菜单。
现象：直播画面卡住不动了。
解决思路：找到点击切换按钮后的点击事件回调，找到切换摄像头的核心逻辑，来找到卡住原因。
1、如果了解ART虚拟机的同学会知道，jni函数和java函数都会调用到art虚拟机ArtMethod的Invoke函数。

输出日志：
findtargetmethod:android.view.View.performClick
ArtMethodInvoke【22955】:;lr:0x4af78c;libart.so:android.view.View.performClick
ArtMethodInvoke【22955】:;lr:0x2e2800;libart.so:java.lang.Enum.toString
ArtMethodInvoke【22955】:;lr:0x2e2800;libart.so:X.Ggh.LIZ
ArtMethodInvoke【22955】:;lr:0x2e2800;libart.so:java.util.LinkedHashMap.<init>
ArtMethodInvoke【22955】:;lr:0x2e2800;libart.so:java.util.HashMap.putAll
ArtMethodInvoke【22955】:;lr:0x2e2800;libart.so:java.util.HashMap.put
ArtMethodInvoke【22955】:;lr:0x2e2800;libart.so:X.DED.LIZ
ArtMethodInvoke【22955】:;lr:0x2e2800;libart.so:X.D5k.onClick
通过fridahooklibart.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退到后台，再回到前台。


以上就是第二钟情况。
好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！
