欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~
转载，本文作者，rexchang（常青），腾讯视频云终端技术总监，2008 年毕业加入腾讯，一直从事客户端研发相关工作，先后参与过 PC QQ、手机QQ、QQ物联 等产品项目，目前在腾讯视频云团队负责音视频终端解决方案的优化和落地工作，帮助客户在可控的研发成本投入之下，获得业内一流的音视频解决方案，目前我们的产品线包括：互动直播、点播、短视频、实时视频通话，图像处理，AI 等等。
为方便大家消化，请参考本篇文章的思维导图
本篇文章的脉络
音视频小程序诞生在2017年4月一辆从深圳开往广州的C7172列车上……
常青带着小程序音视频的方案 乘坐动车前往微信事业群
一次偶然的合作
腾讯云与微信团队合作达成
2016年微信开始启动小程序内测之前，腾讯内部的各个团队就已经开始接到消息。我们每个人都能预感到小程序将会对移动应用场景产生很大的改变。但在当时，我也是刚加入腾讯视频云团队不久，对于这样的信息更多的是关注，而并无太多细致的思考。
2017年伊始，随着大量客户的咨询，我以及我所在的腾讯视频云团队都开始意识到这里的需求特别的旺盛。但由于精力有限，以“小团队大成绩”著称的微信工程师团队很难有精力覆盖所有的应用场景，在音视频这里，小程序仅提供了一些基础的采集和播放能力，比如大家最为熟知的
而就在此时，腾讯视频云的 SDK 产品在经过了一年多的打磨优化之后，已经像是二战初期的零式战机，随时准备“砍瓜切菜”。这里和合作机会虽然不定，但我们团队依然坐上了从深圳总部开往广州 T.I.T 的班车。
经过多次的沟通，以及 jianx 的努力帮助下，这个合作虽然偶然且充满了各种不确定，但最终达成。
技术的挑战
从0到1 困难重重
在音视频应用场景下，两个团队能够达成合作自然是个好事情。但是微信的市场地位也决定了这是一个不容儿戏的战场，所以我们所面临的挑战也异常严峻：
（1）接口必须简单易用，最好一两个标签就能解决问题
（2）满足多种应用场景，既要支持直播又要能够支持实时视频通话
（3）功能必须可扩展，开发者可以根据自身的需要构建出各种个性化应用场景
（4）可维护性好，开发者能够自助排查一些技术问题，而不需要本身是个音视频专家
（5）安装包体积增量足够小，不然微信的安装包体积控住不住
除了高标准的要求以外，时间也是一个非常不利的因素。整个项目留给我们可以证明自身能力的时间只有两周，在短短两周的时间里，我们需要在一个 G2C 项目落地且成功通过产品演示和方案验收。
化繁为简
面对这些挑战，我想到了苏联卡拉什尼科夫所设计的名枪 AK-47 。
之所以这么成功，源于其所贯彻的简单实用的设计理念：回转式闭锁确保了安全性，杜绝了随机事故的可能性；结构简单易拆卸，因此要生产它并不需要特别精密的加工技术，也不需要投资巨大的生产设备，甚至一个普通小作坊就能开工生产。
没错，化繁为简，追求简单可靠，这就是我们需要达成的目标。
攻克技术难关
达成这些并不容易，我们团队一步一步的攻克技术难关
上行和下行
首先，我们要对腾讯视频云现有的音视频体系进行拆解和抽象，也就是把整个体系打散成一个个积木，其中最重要的两块就是：音视频上行（push）和音视频下行（play）。
-音视频上行（PUSH）
就是把自己手机上的声音和画面实时的上传到云端。我们将这部分能力用视频云 SDK 进行实现，并封装成一个叫做
音视频上行
SDK 内部实现机制如上图所示：首先，我们要对摄像头的画面进行捕获，对麦克风的声音进行采集。但是，原生采集和捕获的画面和声音是需要进行预处理的，直接采集的画面可能有很多噪点，所以我们要进行图像降噪；比如， 原生采集的人像里，皮肤可能并不符合人们的预期，所以我们需要进行磨皮和美颜；直接采集的声音可能也有很多的环境噪音，所以我们需要进行前景和后景音的分离然后进行底噪抑制。
经过预处理之后的画面和声音相比于原始采集的一般会有较大改善，因为所有的预处理都是以“讨好”人类的视听体验为目的，所以这一看似不起眼的部分会吸引很多公司在其上做不少的技术投入。举个身边的例子，以 LCD 平板电视为例，SONY 的 LCD 产品线都没有自家的液晶面板（以台湾和大陆液晶面板为主），却能在总体效果上一直领先其它公司，其背后的秘密就是在图像处理（基于图像数据库做超分辨率显示）和背光技术（所有动物的眼睛都是对亮度最为敏感）上的不间断的积累和投入。
画面和声音都经过“粉饰”之后，就可以送给编码器进行编码压缩了。编码器的工作是将一张张的画面和一段段的声音压缩成 0101001... 的二进制数据，而压缩后的体积要远小于压缩前。最后要做的工作就是将编码后的数据通过网络模块发送出去。在在线直播场景中，一般采用的网络协议都是基于TCP的，而在实时通话场景中，所采用的网络协议则是 UDP 为主。
-音视频下行（PLAY）
也叫播放，就是从云端把编码后的音视频数据实时下载下来并实时的播放，这样一来，您就能看到远程的画面，听到远程的声音。同样的，我们将这部分能力用视频云 SDK 进行实现，并封装成一个叫做
音视频下行
SDK 内部实现机制如上图所示：来自云端的数据会直接送给网络模块，但网络不是完美的，总会有时快时慢的波动，甚至会有可能发生阻塞和闪断。如果服务器来一段数据， SDK 就播一段数据，那么网络稍微一波动，画面和声音就会表现出卡顿。我们采用抖动缓冲（VideoJitterBuffer）技术解决这个问题，就像是为网络过来的数据准备一个小的蓄水池，音视频数据先在这里暂存一小会儿再送去播放，这样就可以在网络不稳定时有一定的“应急”数据可以使用。
数据经过缓冲以后，就可以送给解码器进行解码，解码就是把压缩后的音视频数据还原成图像和声音，然后进行渲染和播放。我们采用了 openGL 进行画面的渲染，使用 iOS 和 Android 的系统接口来播放声音。
信号放大器
有了这两个简单的标签，我们就可以进行初步的组合，构建出第一个最简单的应用场景：在线直播。
信号放大器
在线直播是一个非常经典的单向音视频场景，您只需要简单的将两个标签组合在一起即可，
如果是简单的一路上行 + 一路下行，那么我们随便搭建一个中转服务器就可以解决问题了，但这样只能在很小的范围内实现高质量的直播服务，真正要做到高并发和流畅无卡顿，就需要一个强大的视频云。
视频云在这里的作用就像一个信号放大器，它负责将来自
但在线直播方案只能应用于解决单向音视频问题，因为它有个明显的问题，就是延时一般都是在 2秒 - 5秒左右，这是使用