@sche11 有空再搞一下，接起来略麻烦

@lockheart
@KuiLei
@superman
@NotAProgrammer

按照这个页面上的说明，直接下载 APK 试试 👉 https://snapseek.super.site/download-apk%E4%B8%AD%E6%96%87%E6%8C%87%E5%8D%97

@Les1ie 策略确实比较难想

@Alexonx 很好的建议，会在后续迭代优化

@KuiLei 我后续会提供一个单独下载 apk 的链接，感觉 play 的分发规则有点奇怪

@taosimple 是的，本地识别

@lockheart 很奇怪，我这 pixel 4a 也是支持的。但也有反馈和你一样，pixel 也提示不兼容，我暂时还不清楚为什么。

@xm726 服务器已经关闭了，你可以自己部署。

@v7 明天找你私聊一下

@briske 我先看看，之前没咋关注 Shein 的岗位

@miKaSaAkerMan PDD 听起来比较累，后面再考虑（

@leexsh31 我之前面 TikTok RTC 新加坡的岗位，简历状态还是 Interviewing （面试中）呢，两三周没变过了，给 HR 发邮件也没有回复，只能自认为挂了。简历状态不变的话是不是就没法走后续面试其他部门的流程呢？

@cuzval macOS 上有一个 App 叫做 Bear https://bear.app/ ，直接写好然后导出为 PDF 就可以了（导出为 PDF 功能需要付费，好在订阅费比较便宜，也可以随时取消，也有试用期哈哈，你在试用期里面导出 PDF 就就可以不付费了）。

@lee1997

我一般还是用 VS Code 看代码的，也用 VS Code 改代码（ Android Studio 有时候也会用）。

AS 更多还是用于打断点，能打断点比直接去看代码梳理逻辑要容易很多，我之前也写过一篇断点调试的文章（但是现在新版本看评论似乎已经不生效了，可能要调整一下） https://webrtc.mthli.com/basic/webrtc-breakpoint/

除了打断点之外，还需要熟悉一下 WebRTC 的线程模型（和 Android Looper 比较像），以及信号槽机制（可以理解为观察订阅模式），单纯看 WebRTC 代码基本够用了（ WebRTC 也封装了大量的第三方库，但这就是另外的话题了）。

最后如果你用 AS 看代码的话，直接导入 WebRTC 源码，索引会爆炸的（ CPU 占用率 100%），所以要屏蔽一下第三方库的索引目录，比如可以在项目的 build.gradle 里这样写：

```
idea {
module {
excludeDirs.add(file("${webrtcIncludePath}/testing"))
excludeDirs.add(file("${webrtcIncludePath}/third_party"))
excludeDirs.add(file("${webrtcIncludePath}/tools"))
}
}
```

webrtcIncludePath 就是你本地的 webrtc/src 的绝对路径。

@BruceLi 不考虑回西安了，我不是西安人

@anjingdexiaocai 八月才开始找工作呀。之前都在搞 GPT ，做了几个小玩意自己不是很满意

@androidzai 主动提离职的，当时公司有 n+2 （可以搜一下当时的虾皮新闻）。不走就继续干，现在不用找工作了哈哈。

@lee1997

1. 如果是运行在 Native 上，你需要先搞定编译流程（对于 Android 主要是在 Mac 上编译比较麻烦，需要改造编译脚本；你也可以用专门的 Linux 编译机编译）。

2. 对于服务端，一般来说会选择 SFU 架构，这方面有很多开源实现，我们最早也是基于 mediasoup 改造的。mediasoup 也有第三方开发的 Android / iOS demo 可以参考，但最终并不是直接使用这些 demo ，大部分逻辑都重构了。

3. 如 2 所述，为了方便后续扩展和维护，你需要搞懂具体用到的框架的连接流程，比如信令的发送时机、断网重连怎么恢复流的状态，用户（主播或观众）的状态等，这些可以理解为状态机的迁移过程。也方便后续改造或者精简信令（提升连接速度）。也会涉及音视频采集和渲染的工作，但是这部分 WebRTC 本身已经处理的挺不错的，不用过多关心。

4. 最终呈现出来的对外 SDK API 的形式可以参见声网的文档（对于不同业务，需要的功能是声网的子集） https://docportal.shengwang.cn/cn/All/API%20Reference/java_ng/API/rtc_api_overview_ng.html

5. 如 4 所述，公司内部的 SDK 需要对不同业务的特点做支持（问题排查）和优化，比如银行认证关心通话成功率和画面清晰度、直播关注延迟和流畅度等。如果之前没有的特性也需要添加，比如直播在视频帧里要添加 SEI 信息，客服可能要添加铃声的混音等等，需要对音视频格式和 FFmpeg 混音有一些了解（其实我之前也没什么了解，现学现卖）。

还有其他的内容，比如协助集成一些自研的网络库、音频 3A 算法之类的，也是需要对 WebRTC 的源码有一定的熟悉度。嗯，大概就是这些。

@choochoofly 视频格式有一定关系，相同画质但是更高的压缩率肯定能节省带宽。不过更多应该还是集中在传输层面的优化，怎么更好的解决网络拥塞问题（比如是不是可以调整一下 FEC 之类的，这些都可以有一个专门的岗位研究了）。