《关于技术选型》
2020 年带一个创新业务,做的是异步视频沟通表达工具,可以理解为 loom + mmhmm 的结合。
印象很深刻,当时前端研发负责人,想在新项目上实践新的技术栈,采用了当时有点开始流行的 Rust 框架,但那时,Rust 生态很不完善,好用点的 UI kit 库都没有,一些功能的实现都得前端自己摸索,那时候两个全职前端同学,实现功能就很慢,而且存在各种还原度问题,性能问题,费了很大劲,磨了两个月才出第一版 Demo。
后来有一次我去剪映那边交流,他们也是做的桌面客户端,就问他们前端负责人技术栈选择问题,他们用的是 QT,算是老牌的做客户端应用的常用框架。
另一件事,当时大的团队主体是做音视频会议的,音视频会议用的是 RTC 传输,而新产品正好非常需要录屏视频快速上传和生成的能力,于是当时就使用了 RTC,结果导致录制完的视频,一方面清晰度不足,时不时因为网络波动,导致画面模糊;另一方面,黑屏、音画不同步,又花了很多时间尝试解决。
实际上,当时竞品采用的是简单的分段上传技术,就是每隔几十秒就上传一段录屏完的视频,然后服务器端合成一个视频,让用户感觉是速度很快,有媲美实时的感觉,另外也能保证视频的清晰度。
后来,我们做 Chrome 版,用市面上大部分竞品的技术方案,就花了 2 周时间,产品效果很好。
大部分不靠拼技术吃饭的创业团队,生死时速,业务为王。
显示更多