

声网高纯：领域和方向要聚焦，用最专业的方法做最专业的事丨人物专访

RTE开发者社区

2022-10-12

导读：英特尔每天下午 4:55 会响起“灯，等灯，等灯”的下班铃，是真的么？

READING

前言

本期「声网开发者 x 人物专访」的受访者，是声网高级架构师 @高纯。

高纯是 W3C 组织的 AC REP(Advisory Committee Representative)，还是一名管乐爱好者，陆陆续续的吹过几年的小号。

在加入声网前，纯哥曾在被戏称为“上海三大养老院”之一的英特尔工作了 7 年，参与了如 Meego Browser、WebKit、Chromium 等众多知名项目的研发；蓬勃发展的大环境，让七年之痒的纯哥加入了创业的阵营。

短暂的创业经历用他的话来说“不太成功”，但也让他明确了下一份工作的方向 —— 公司的业务领域和自身的研究方向一定要聚焦，用最专业的方法做最专业的事。

在朋友的推荐下，纯哥加入了声网。目前主要负责声网 WebRTC 在端侧的技术研发。

在这次采访中，纯哥分享了为什么离开 Intel 去创业、为什么加入声网，分享了对 WebRTC 以及 Web 端音视频技术的理解与经验。以及，英特尔每天下午 4:55 会响起“灯，等灯，等灯”的下班铃，是真的么？

*本文为声网开发者 - 人物专访栏目，内容根据和高纯的对谈内容整理，文内观点仅代表个人。

观点前瞻：

公司业务领域的聚焦，才能保证自己的专业技能得到持续积累；研究领域的聚焦，能够确保自己积累的优势技能可以创造出最大的价值。

由产品经理主导研发工作的好处是推出的产品会相对比较成熟、更加面向用户，有些时候工程师也需要试着站在产品的角度来思考问题。

RTC 技术和多媒体实时处理技术向来以高复杂度著称，而在 web 平台上由于性能和可扩展性问题，其所受的制约尤为明显，但新一代媒体处理与通信的标准，为 Web 多媒体处理和传输技术的发展开启了崭新的局面。

三大养老院的名声当然是一种戏称，这种称呼突出的是相对宽松的工作环境和自由的工作氛围，这当然是与现今互联网行业的内卷文化是形成鲜明对比的。

到底什么样的公司才是真正的技术型公司，究竟给行业带来了什么影响，我想这是在当下尤其是在互联网行业发展遭遇瓶颈的大背景下大家需要思考的问题。

Part 1- 职业经历

1、介绍下您的第一份工作吧

2010 年，我通过 Intel 校招进入开源技术中心（OTC）工作，参与英特尔和诺基亚合作的 Meego OS 项目的研发。从该项目起，我便开始了 Web 引擎及 OS 相关的技术工作。直至今日我依然从事 Web 平台相关的技术工作。

在 Intel 工作期间，我先后参与了 Meego Browser，WebKit，Chromium，Tizen WebRuntime，Crosswalk 等开源浏览器和 Web 引擎的研发，以及 Chrome OS、Android Auto、AliOS 等操作系统图形栈的开发工作。

2、在英特尔时期，参与过印象最深刻的一个项目是什么？

我在英特尔的工作内容除了为浏览器和 Web 引擎进行功能开发和优化，还有很一大部分比例是参与团队发起的开源项目。这些开源项目中包含了各主要系统平台的 WebRuntime。这里需要特别提到的是一个完全由中国团队发起和主导的安卓 Web Runtime 项目 —— Crosswalk Project，Crosswalk 的诞生和终结有非常特殊的时空背景。

我们知道，安卓系统早期版本之间的技术跨度非常大，而它所提供的 WebView 组件在不同安卓版本上基于不同的基础设施实现，比如 android 4.4 及之前版本基于 WebCore+V8 实现，android 5.0 之后基于 Chrome 实现。而这段时间正是 HTML5 标准定稿之前的快速发展期，不同安卓版本的 WebView 对 HTML5 标准的兼容性出现了比较大的差异。同时不同设备厂商对 Android 系统不同程度的定制也造成了 WebView 能力的差异。

在这几项因素的共同作用下，就导致了 Android 系统严重的碎片化问题。开发者基于 WebView 开发的 Web App 在不同的安卓设备上需要面对严重的兼容性问题。而另一方面，由 Google 主导的开源浏览器 Chrome 发展迅猛，凭借其强大的功能、性能以及对 HTML5 标准的兼容性迅速成为市场份额最高的浏览器产品。

正是在这一背景之下，Crosswalk 项目应运而生，该项目比较创新的地方在于提供了一个基于 Chromium 内核的随 App 打包的 WebRuntime，从而使 App 脱离系统 WebView 得到对 HTML5 标准的支持。在 2015 年的 Google IO 大会上，Crossswalk 项目被 Google 宣布为当时安卓平台 Hybrid App 开发的最佳技术方案。

Crosswalk 项目创建之初有一个很酷的愿景，就是随着 HTML 标准的发展和操作系统对Web标准更好的原生支持，自己最终能够消失在开发者的视野中。最终它完成了自身的使命 —— 促进 HTML5 标准和生态的发展。最终该项目于 2017 年被 Intel OTC 宣布停止维护。

这个产品从今天看来虽然已经有点遥远，但它带给我的启示是重大的。Crosswalk 从诞生到流行，一个决定性的因素就是它真正满足了 Hybrid App 开发者的诉求，解决了开发者长期关注却得不到解决的痛点。而开放的技术路线和项目运营也促进了生态的发展，使的更多开发者加入到 HTML5 和 Web Hybrid 开发生态当中。

这正如今天我们在声网所从事的事业，正是由于声网对音视频行业的长期耕耘，产品和技术团队对用户核心诉求的持续关注，各项目组以开放的心态接受来自用户的反馈并不断落地到产品之中，才和行业伙伴一同造就了如今音视频行业的繁荣。值得一提的是声网一直倡导拥抱开源，并为社区贡献了不少优质的开源项目，从而构建了广泛的音视频技术生态。这在今天的行业背景下更加显得难能可贵。

3、谈谈为什么离开英特尔加入声网？源于什么契机？

在离开 Intel 加入声网之前其实我有一年不算成功的创业经历。

从 2016 年下半年开始，由于行业和技术生态的变化，Intel OTC 进行了多次的业务和组织架构调整，我的工作重心也从上层 Web 引擎技术向 OS 图形栈拓展。然而 OS 项目从开发到最终交付用户是一项周期很长的任务，缺乏及时的用户反馈会使自己工作的价值变得难以评估。

另外从 2014 年之后随着国内互联网行业发展，我所在团队的成员陆续离开英特尔，进入国内各大科技公司并承担 Web 引擎或国产 OS 项目的关键职责，他们陆续给我带来了许多新奇的见闻，也逐渐令我心生向往，于是 2018 年 3 月在和新上司的第一次对话中我提出了离职。

离开 Intel 之后，我成为了一家创业公司的联合创始人，并担任首席架构师的工作，公司的业务重心是产业互联网技术中台系统的研发。在此期间我的主要工作是是产品架构设计、技术路线规划、运维体系建设、投标讲标等。在此期间，我们成功上线了某大型国企和民营企业的中台系统，业务涵盖零售终端、财务、物流、电商等多个领域。然而由于行业需求的转变以及公司运营环境等不可控因素的影响，在创业 1 年左右我最终还是选择了离开。

在参加工作之前我经常在思考究竟需要一份怎么样的工作，Intel 的工作经历和这次创业经历很好的回答这个问题，那就是公司的业务领域和自身的研究方向一定要聚焦。

公司业务领域的聚焦才能够保证在一个相对比较长的时间内自己的专业技能得到持续积累；而研究领域的聚焦能够确保自己积累的优势技能可以创造出最大的价值。当然聚焦并不意味着对技术广度的轻视，而是以最专业的方法来做最专业的事情。

业务聚焦方面，声网无疑是做的很好的。其实在加入声网之前我对公司并没有太多了解，但在 Intel 前同事的热情推荐下，我对声网专注音视频业务的理念有了强烈认同，觉得这是一个值得一试的地方，于是在他的引荐下加入了声网。

4、加入声网后，最大的感受是什么？与之前的工作形式、环境有哪些变化？

加入声网后最大的感受就是公司在音视频行业的技术沉淀非常深厚。

以大前端为例，各技术团队所承担的研发任务涵盖了音视频处理算法、编解码器、高性能计算、音视频工程化、网络体验、Web 平台与内核、工程质量测评等各关键领域，而这些领域的划分基本对应了大前端的组织架构划分。如此细致的职能划分在整个音视频行业都是非常少见的，这也体现了声网在音视频技术领域的专业性。

相较在英特尔的工作，声网的工作形式更加敏捷，产品从设计、开发到交付的周期相较之前大大缩短，更加偏向一种小步快跑的方式进行。开发人员地工作成果能够在一个较短地时间内交付到用户手中。

在英特尔开源技术中心，研发工作更多地是工程师在主导，相关产品从构思、研发、上线也主要是技术人员在驱动。而在声网，产品经理的角色更加突出，产品定位、功能特性、定价、研发周期等关键决策往往由产品经理所主导。这带来的好处是推出的产品会相对比较成熟、更加面向用户，所以有些时候工程师也需要试着站在产品的角度来思考问题。

另外一个不同的地方是对客户的全方位支持和全生命周期服务，声网的企业文化始终把客户放在最重要的位置，技术团队除了产品研发，还有产品探索和客户成功团队，他们与产品团队一道构成了整个服务体系的闭环，这在很多云服务产商都是难以做到的，也是奠定声网行业领导者角色的基础之一。

作为研发人员，这就要求我们不仅在技术上有所突破，同时也要持续关注用户的诉求，在客户遇到问题的时候也往往需要直接参与到客户问题的分析之中。这些都是和以前的工作非常不同的地方。

Part 2 - WebRTC 技术

5、目前在声网主要负责哪些业务和工作？

目前主要负责的是声网 WebRTC 在端侧的技术研发，工作内容包括 Web 平台实时音视频处理与 AI 技术的研发和落地，Web 下一代 RTC 技术架构的研究与探索，以及 Web 云录制业务中 Web 引擎相关技术的研发。

6、好像现阶段音视频领域都在研究 Web 端？Web 端相对于原生应用而言，能提供哪些方面的能力或优势？

Web 应用相较 Native 应用存在四个方面的优势：

一是即点即用特性，Web App 无需下载、安装等复杂的动作，用户只需点击链接即可使用，这就大大降低了产品触达用户的门槛。同时 Web 应用的更新和发布无需经过应用市场等渠道，更新和迭代更为快速。

二是 URL 的传播属性，我们知道在 Web 世界所有资源都由一条 URL 来表示，URL 在社交媒体或推广平台的分享和传播就意味着 Web App 本身的传播，因此 Web App 在快速传播方面具有天然的优势，是产品、服务和流量的一个重要入口。

三是 Web 平台的标准化属性，如今的 web 生态已经是一个高度标准化的生态，web 平台语言和功能的演进由几个主要的标准化组织在主导。因此尽管在 Web 生态中各种技术框架层出不穷，但其所依赖的 Web 基础设施的底层逻辑却高度统一。也就使得只要统一在 Web 技术生态下，开发者就可以便捷的构建出强大的跨平台应用。

四是 Web 平台的自包含特性。随着 HTML5 标准的演进，Web 平台已经能够提供越来越多的原生功能，从 2D/3D 处理与渲染、音视频处理、机器学习、媒体编解码、VR/AR、数据传输与加解密、资源离线存储，WebAssembly ，到无障碍技术的支持，Web 平台提供的基础组件已经无所不包，基于这些基础组件即可开发出广泛而具有良好用户体验的 Web 应用。

以声网音视频算法在 Web 平台的落地为例，我们在获得算法团队的模型和算法后，总是能够在第一时间完成其在 Web 平台上的落地，这在很大程度上得益于 Web 平台上丰富的既有功能特性。比如在实现虚拟背景的动态背景功能时，只需利用 <video> 元素的自有的解码和渲染能力结合 WebGL 对视频内容的处理能力即可快速实现这一能力。相较 Native 平台研发周期大大缩短。

7、基于 Web 端搞音视频应用，技术难点和门槛是什么？有哪些评估指标？

刚才提到了 Web 平台的优势，其实 Web 平台的劣势也是显而易见的，最主要的两点就是性能和可扩展性。

Web 作为一个跨平台的技术方案，web 引擎的实现不可避免地需要考虑 x86、ARM、RISC-v 甚至 LongArc 等各硬件架构的兼容性问题。以最近热度非常高的 WebAssembly 技术为例，虽然它提供了对 128 位的 SIMD 指令的支持，在利用 cpu 并行处理能力方面相较 JS 及 asm.js 技术已经有了很大地提高。但是出于虚拟机指令兼容性的原因无法使用更高位宽的 SIMD 指令进行运算优化，这就使得在 x86 架构下拥有 AVX2 及 AVX512 指令的高端CPU的运算能力无法得到充分发挥。

而 Native 技术则不然，基于 Native 技术的产品能够尽可能地利用平台相关的特性进行优化，从而得到到更高的并行运算性能，尽管 Native 应用可使用的某些优化手段带来的副作用是功耗的陡然上升和系统散热问题，但在技术上至少能够给到开发人员更多的回旋空间。

在可扩展方面，我们知道浏览器是能够加载任意的 URL 资源来运行的，这其中当然也包括大量的不安全内容。因此浏览器内核的设计永远需要考虑到系统安全性和用户的隐私。这就使得浏览器在功能性和安全性上需要有所取舍。

由于早年在 IE 上的 AtiveX 和 Chrome/Firefox 上的 NPAPI plugin 遭到大量软件开发商的滥用，使得用户的桌面沦为流氓软件的战场，因此相关的原生插件技术已经在多年前遭到主流浏览器产商的废弃，浏览器已经不再提供任何原生机制来扩展浏览器的能力。当然运行在 Sandbox 中的 WebAssembly 在一定程度上解决了JS计算能力不足的问题，但是它并不能解决 Web 平台上的各项 IO 需求。这就使得开发者只能利用浏览器既有的各项 API，从而无法完成一些高度定制化的任务比如特定传输协议的实现、应用数据与媒体数据的帧级同步等。

RTC 技术和多媒体实时处理技术向来以高复杂度著称，而在 web 平台上由于性能和可扩展性问题，其所受的制约尤为明显。与之相关的应用不论是开发体验还是运行效率都备受挑战。

当然，近年来面对这些问题 W3C 相继推出了一系列新一代媒体处理与通信的标准，为 Web 多媒体处理和传输技术的发展开启了崭新的局面。然而标准的演进和落地是一个漫长的过程。在这个过程中，Web 产品的研发人员依然需要通过自己的聪明才智找到兼顾产品体验和运行性能的最优解。

8、对于目前非常热门的 WebAssembly + FFmpeg 方案，您的看法是什么？

WebAssembly + FFmpeg 方案在两年前其实声网 WebRTC 团队就曾经进行过尝试，并且落地到针对移动端 H5 场景的产品“RTS”中，当时这个方案主要用于解决的音频解码在不同设备上的兼容性问题。

刚才提到了 WebAssembly 技术对于提升 Web 平台的计算能力起到了重要作用，但是由于无法利用全部的硬件特性，WebAssembly 技术还无法完全达到 Native 的计算性能，这就使得我们在进行 WebAssembly + FFmpeg 技术实践时需要对症下药。

比如针对低码率的音视频场景以及对算力要求相对较小的 h264、vp8 等视频格式的编解码场景使用该方案往往能够取得较好的效果；而针对 HEVC、AV1 等视频格式，尤其是高码率场景，WebAssembly + FFmpeg 方案并无法提供足够的算力。

实际上不仅是使用 WebAssembly，即使是直接使用原生技术开发软件 Codec 其性能和效率也相当有限，对于 HEVC 和 AV1 格式的编解码还是需要优先寻求硬件加速方案。基于 Chrome 内核的 Edge 105 目前已经默认提供了 HEVC 硬解的支持，不过它是基于 Windows 系统的 HEVC 插件，需要终端用户付费使用。在 Chrome 104 版本已经提供了 HEVC 的硬解能力，但是需要通过启动参数将这个能力打开，相信在未来的版本它会很快成为一项默认能力。

而在移动端，目前在部分机型上 Chrome 浏览器已经默认提供了 AV1 格式的硬解支持，当然这需要需要设备硬件提供相应的能力。针对上述平台和格式，Web 开发者可以尝试时使用 WebCodecs API 进行硬解，从而获得更佳的性能。

9、WebRTC 或者 RTC 领域，在技术上有哪些可预期的发展方向？在未来还有哪些可期待的应用场景？

前面有提到 Web 平台上的一些可扩展性问题，这个问题在 WebRTC 上也很明显。作为一个 RTC 整体技术方案，WebRTC 提供的能力虽然够用但却并非最好，同时也缺乏足够的灵活度来整合厂商的自有能力。比如基于现有的 WebRTC 技术架构，无法实现与产商自有的传输协议、QoS 算法以及 Codec 的协同工作，在实现自有 3A 算法及视频增强算法时的开发体验也比较差。无法传输 Alpha 通道数据，缺少应用数据与媒体数据的同步机制等问题，也使得它在面对云游戏、元宇宙等应用场景时显得力不从心。

面对 WebRTC 的这些问题，W3C 标准草案中推出了 WebRTC NV 的概念。WebRTC NV 是什么？其实标准里并没有给出具体的定义。它不像 WebRTC 1.0 有明确的 spec 来定义传输相关的 PeerConnection 接口以及媒体采集和媒体流表达规范。

对于 WebRTC NV（Next Version），W3C 只给出了一个《WebRTC NV Use Cases》文档。这个 spec 里定义了 12 种典型的 Use Cases，这些 case 涵盖了隐私与安全、音视频特效、机器学习、IOT、VR 游戏、简化的信令系统、低延迟广播、去中心化消息等。针对每种 Case 同时列出了若干条浏览器所要满足的功能特性，而每个功能特性背后就对应于一项新的 Web 技术组件。这些组件包含且不限于：MediaStreamTrack Insertable Streams、WebRTC Encoded Transform、WebCodecs、WebTransport、WebGPU、WebAssembly 等。

他们分别用于提供媒体前后处理、媒体编解码、编码数据处理、基于 Quic 的网络传输、GPU 渲染与应算、CPU 运算等能力。目前这些新的Web组件一部分已经在浏览器上落地，并且仍然处于快速发展之中。使用这些新的技术组件结合 WebRTC 或者完全脱离 WebRTC 可以构建出 Web 平台上新的 RTC 应用架构。

10、声网在这方面在做哪些工作？

在 WebRTC NV 各相关技术组件在浏览器落地后，我们会在第一时间针对组件的功能特性以及对 SDK 产品的潜在价值进行研究，并适时推进其在 Web 产品中的落地。比如在 Chrome 94 正式开放 MediaStreamTrack Insertable Streams API 之后，我们很快就使用新的 API 为虚拟背景以及美颜插件进行了重写，使其在 Chrome 上得到更高的运行效率和更好的交互响应。

在 WebCodecs 和 WebTransport 方面，我们也进行了比较长时间的探索，研究的主要内容是建立 WebRTC 之外的媒体传输通道和编解码方案，这涉及到整体 pipeline 的实现也涉及到 QoS 算法在 WebTransport 不可靠传输通道上的移植。

最近我们也在 WebRTC 往 WebAssembly 上的移植做了不少工作，我们的目标是将 WebRTC NV API 与 WebRTC 的处理管线、算法相结合，这样即利用了 NV API 的灵活性又弥补其在不可靠传输时网络 QoS 算法上的不足。这个项目我们的长期规划作为一个开源项目来推进，当然这要等到它具有一定的成熟度之后。

事物的发展是曲折前进和螺旋式上升的，这些新的 Web 组件也一样，由于推出的时间并不长，其成熟性还有待提升。我们在实践的过程中也发现了它们不少的问题，这里既有和硬件编解码器的兼容性问题，也有颜色空间上的 Bug。

在后续的工作中，我们除了继续推进 Web NV 新技术架构的落地，同时也会持续关注 Web NV 基础设施本身的建设，积极加入到开源社区中为这些问题的解决贡献力量，和行业伙伴一道为共建 Web 下一代 RTC 技术生态而努力。

11、最后，我们来展望下 Web 端技术发展的趋势吧

这个话题实在是太大了。Web 技术所涵盖的内容非常广，W3C 的各项规范草案中甚至还包括由中国互联网公司联合推进的 Mini Apps 小程序标准。而最近关于 Web 3.0的讨论也很热烈。但在这里我想还是列举两个离我们比较近且有重大影响的技术标准来讨论一下。

首先是传输协议层面。在今年的 6 月 6 日，IETF 在 RFC9114 发布了 HTTP/3 推荐标准。这对 Web 来讲是一个重要的里程碑。

HTTP/3 基于 QUIC 协议实现，而 QUIC 构建在 UDP 之上。因此它解决了 HTTP/1.1 HTTP/2 使用 TCP 进行传输时遇到的线头阻塞问题，能够提供更低地的延时。在一些场景下相较 HTTP/1.1 甚至能实现 3 倍的速度提升。

目前在端上已经有超过 3/4 的浏览器能够支持 HTTP/3 协议，然而在服务端的支持情况相对就要差很多。我们知道传输层协议 Quic 已经发展多年，并且已经具有了丰富的应用生态，服务端有大量的开源项目实现了 Quic 协议，这里面也不乏国内互联网大厂开源的项目。然而在 HTTP/3 层面，目前支持得比较好的开源服务器项目并不多，以 nginx 为例，在它 roadmap 里提到要到 2022 年底才能会实现对 QUIC 和 HTTP/3 的完整支持，这里面还不包含之后的性能优化，所以要在生产环境中使用 nginx 提供 HTTP/3 能力还需要更久的时间。相信 HTTP/3 Server 逐步成熟之后，整个 Web 的网络体验会有较大进展。

另外值得提的一点和媒体处理相关的能力。通常针对图像、视频等多媒体内容进行实时处理需要利用 GPU 能力。目前在 Web 平台上相对成熟且兼容性比较好的选项就是使用 WebGL，WebGL 基于 OpenGL ES 标准实现。然而 OpenGL 是一项历史悠久的图形标准，他提供的图形接口已经越来越不适合现代 GPU 的功能。因此 Khronos 在 2017 年在发布了 OpenGL 4.6 之后就停止了 OpenGL 标准的推进，转而发展下一代图形标准 Vulkan。

同时 Apple 和微软分别也推出了下一代图形引擎 Metal 和 D3D12。针对这些变化，Web 平台出现了基于 Vulkan、Metal 及 D3D12 的图形标准 WebGPU。利用 WebGPU，Web 上的图形应用性能可以得到数倍的提升。目前 WebGPU 在 MacOS 上的 Chrome 上以默认可用，其他平台出于安且性原因暂未默认启用，相信在这些问题解决之后。WebGPU 能给图形应用和媒体处理带来更佳的体验。

（正文完）

番外篇

“灯，等灯，等灯”

阿遂：业内流传在上海有“三大养老院”(IBM, Intel, EMC)，其中英特尔每天下午 4:55 会响起“灯，等灯，等灯”的下班铃，是真的么？

高纯：三大养老院的名声当然是一种戏称，我想这种称呼突出的其实是一种相对宽松的工作环境和自由的工作氛围，这当然是与现今互联网行业的内卷文化是形成鲜明对比的。同时这个称呼也反映了在外企技术人员相对更愿意在这个环境中长期致力于某个领域并进行深入研究的现实。

关于下班铃，由于英特尔在上海的研发中心位于闵行的紫竹科学园区，交通相对不够便利，因此很大一部分员工主要依靠公司班车通勤。在 Intel 每天可以看到的一个壮观的场景就是下午 5 点驶离紫竹园区的班车长龙，所以一到 4:55 就会有标志性的“等灯、等灯”音乐响起，提醒大家该赶班车了。除了 4:55 的等灯，Intel 紫竹办公室每到晚上 7 点还要关灯，当然关闭的是工作区的主要照明，如果你继续呆在办公室，还可以使用 Cubic 上的两盏小灯继续工作。

这里我想强调的一点是，宽松的工作环境并不意味着虚度光阴和养老，实际上在 Intel 的很多项目组也会面对较大的工作压力，这既有来自项目进度的压力，也有内心一份责任的驱使。尤其是在一些跨团队的全球项目中，由于时区关系很多 Review 和讨论都需要在深夜开展，同时作为全球化项目团队的一员，如何呈现中国团队的专业和素养并得到海外同事的信任也是一门很大的学问，这些都是远远超出 4:55 这个时间点之外的。

刚才聊到我在英特尔工作了 7 年，其实那里工作 10 年甚至 15 年以上的员工相当常见，在漫长的工程历练和技术熏陶下，Intel 培养了许多业界技术大牛，从半导体到系统内核/编译器再到系统中间件，从 Intel“毕业”的技术人员如今活跃在国内各大科技企业并发挥重要作用。以我们声网 WebRTC 团队为例，先后有三位 Intel 前员工加入到这里，和大家一起实现了 WebRTC 业务从无到有再到支撑全球业务的跨越。

近年来，很多的企业都以科技公司自称，但是到底什么样的公司才是真正的技术型公司，究竟给行业带来了什么影响，我想这是在当下尤其是在互联网行业发展遭遇瓶颈的大背景下大家需要思考的问题。

关于声网开发者 x 人物专访

「声网开发者」系列人物专访是声网推出的文字类访谈节目。区别于纯粹的技术分享，我们相信开发者本身的思想与经验具备更加丰盈的价值。希望通过这个栏目链接优秀开发者，挖掘技术黄金时代背后，源于每一位开发者个体的力量。

往期回顾：

关注「声网开发者」

关注实时互动领域的

技术实践、行业洞察、人物观点

☟☟☟

【声明】内容源于网络

RTE开发者社区

RTE 开发者社区是聚焦实时互动领域的中立开发者社区。不止于纯粹的技术交流，我们相信开发者具备更加丰盈的个体价值。行业发展变革、开发者职涯发展、技术创业创新资源，我们将陪跑开发者，共享、共建、共成长。

内容 1122

粉丝 0

RTE开发者社区 RTE 开发者社区是聚焦实时互动领域的中立开发者社区。不止于纯粹的技术交流，我们相信开发者具备更加丰盈的个体价值。行业发展变革、开发者职涯发展、技术创业创新资源，我们将陪跑开发者，共享、共建、共成长。

总阅读1.1k

粉丝0

内容1.1k