共计 9998 个字符，预计需要花费 25 分钟才能阅读完成。
前言
本期「声网开发者 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 人物专访
「声网开发者」系列人物专访是声网推出的文字类访谈节目。区别于纯正的技术分享，咱们置信开发者自身的思维与教训具备更加丰盈的价值。心愿通过这个栏目链接优良开发者，开掘技术黄金时代背地，源于每一位开发者个体的力量。
