共计 1074 个字符,预计需要花费 3 分钟才能阅读完成。
v1.3.2-release 正式公布啦~
该版本上新了 Scrcpy 投屏,然而安卓投屏曾经有 MiniCap 了。到底 Scrcpy 能带来怎么的体验呢?
以往 Sonic 应用的 Minicap 投屏
如果咱们把 Minicap 画质压缩到 80,咱们能够看到投屏成果清晰度还是算高的:
而后咱们看一下带宽:
很显著,清晰度达到了咱们的要求,然而带宽切实是太高了,这还是我略微压缩过的,如果是一些分辨率稍大一点的手机,可能每帧达到 1M 左右,会造成 FPS 降落,而且局域网带宽重大负荷。
于是 Sonic 之前应用的是 Minicap 官网说的形式:
Usable to very smooth FPS depending on device. Older, weaker devices running an old version of Android can reach 10-20 FPS. Newer devices running recent versions of Android can usually reach 30-40 FPS fairly easily, but there are some exceptions. For maximum FPS we recommend running minicap at half the real vertical and horizontal resolution.
压缩投屏的分辨率来取得更高的 FPS,踩过不少坑之后,拿到的清晰度就是咱们看到的
能够看到图片的文字都曾经比拟含糊,然而带宽的确升高了不少,FPS 也达到了顺畅的水准:
除此之外,我还做了丢帧,雷同图片的间接不发送,其余的抛弃三分之一的帧,然而带宽还是比拟高。
当然,Minicap 还有一个很致命的毛病,兼容性太差了,不仅小米、vivo、LGE 有兼容性问题,最新的华为 P50 都曾经无奈兼容了。
Scrcpy 的晋升
Scrcpy 咱们将 socket 桥接过来解决,间接发送 h264 裸流给前端渲染,清晰度是怎么样的呢?
能够看进去,投屏清晰度曾经和 Minicap 最清晰的时候有得一拼了(实践上比 Minicap 要略微清晰),那么他的带宽是多少呢?
对你没有看错,一帧根本不超 10KB!
那么 Scrcpy 带来的投屏体验天然是很不错的,那为什么 Sonic 不间接舍弃 Minicap 呢?
Scrcpy 也有一个毛病,就是会造成 CPU 功耗减少、设施发热会更重大一些,我认为这种危险应该让用户去衡量,于是将两种投屏形式都做进去,让用户能够切换着应用。
Scrcpy 提供不少好的思路,iOS 目前始终用 wda 的 mjpegserver,带宽耗费和 FPS 都没能达到称心的水平,接下来,须要对 iOS 的投屏也要做一番优化了!