@singerll 实时音视频场景 400ms 的延迟都受不了，打游戏你延迟 1s 和 16ms 的差距对用户真的没有卵用吗…？

是不是你经常切换分支？如果切换分支会把之前的内存也保存着

也不是所有的小公司都值得加入。甄别好公司非常困难。在行业下行阶段，大公司概率上活得好点。就算被裁起码也有赔偿。小公司倒闭几率更高。

我之前也在中小公司待过，还是有很多收获，但是还是那句话，甄别和遇到好公司概率非常低，你本身也要足够优秀和有一定的运气。比如：

1. 恰好正确的行业：实现正向盈利，不会因为倒闭而匆匆换新工作导致持续性不强、简历不好看

2. 核心业务的非核心团队：参与核心业务但不需要花时间应对太多的业务导向安排，比如业务值班、大量的运营类业务等

3. 技术团队小：灵活并且技术选型自由度高，你将有更多技术实践的自由，只要对事情负责到底

4. Leader Open 且辐射能力强：层级扁平、凝聚力更好、氛围更轻松，可以提供公司底线之上较高的自由度。

当然每个优点也有相应的缺点和隐患：

1. 创业公司营收压力大、业务变动非常快：相应的员工的压力也更大，体现在技术这边就是「倒排期」、需求管理和版本规划混乱、加班等

2. 非核心团队在技术话语权比较低：难以撬动其他技术团队（后端、测试）一起推进或改进存量业务

3. 技术团队小：如果没有 Tech leader ，那么需要直接对接需求整个周期，非常占用时间；没有专门负责效率和基建的同事，有时候这部分还是非常花时间的（比如基建的稳定性维护等）；规范性靠自觉

4. 非常看 Leader 个人风格，垃圾 Leader 会 PUA ，好 Leader 会抗事带领大家一起前进。

读肯定是可以读的，如果你只是需要显示到 iv 上，直接调用 iv 的 api 就可以了。如果你要自己操作数据，那需要 open input stream

接个小米的音响，触发解锁失败就播放：“Big brother is watching you” 😆

对于客户端来说，还是 Json 方便扩展，不然后续接口加参数，传参地方都得修改。

感谢分享，听播客完全想象不出真实样貌😂

@noparking188 理论上都可以收拢到 item 对象里的，约束和复用程度更好～

一般第二种多点，不过关于你这个特例，其实可以更简洁：

https://i.imgur.com/YtLPUhj.png

公网时延不会很高吗……到服务器的时间都够来回两次查询了。还是部署路由器好点？

开发挺舒服的。就是虚拟机跑不了比较老的版本，因为老版本基本是 x86 的，这对测试兼容性有点麻烦。其他都舒服。肯定比 19 mbp 舒服。不过建议加钱上 m1 pro ，毕竟编译多线程更快。

有点像这个

https://raw.github.com/wiki/ReactiveX/RxJava/images/rx-operators/zip.png

http://reactivex.io/RxJava/javadoc/rx/Observable.html#zip-rx.Observable:A-rx.functions.FuncN-

可以参考我在下面帖子里的回答。先看 ffmepg 的文档吧。

https://www.v2ex.com/t/808095

最精确查找是要逐帧解码的，ss 也应该应用到输出文件（-i 参数值之后）。
又要快又要准，可以先 ss 在输入前指定位置，再 ss 指定输入后的位置…

参考官方文档： https://trac.ffmpeg.org/wiki/Seeking

很棒，但是最想知道版权问题。希望可以标注一下。

一方面需要开发者开发：启动多进程前台服务常驻通知栏。
另一方面需要你把该 APP 加入到白名单中。

微软自家的 powerToys 和菲菲更名宝贝。

@cathedrel 因为必须 request 通过才行呀。提起 issues 只是第一步而已。处理完仓库的提交信息，标记为 ready 才会进入打包流程。

https://gitlab.com/fdroid/rfp/-/issues?label_name=ready

就像你说的，可以创建一个 issues 来申请 F-Droid 构建。如果 issues 通过了，F-Droid 会把这个项目的信息加入到 F-Droid/Data 仓库，然后定期自动编译打包发布到 F-Droid 。时间可能在一到两周。不过打包需要原仓库打过 tag，这个可能需要你自己 fork ？

https://gitlab.com/fdroid/fdroiddata