前言
GoSpark团队，产品和运营由花姐和老曲亲自操刀。技术团队由严哥牵头，国涛负责后台，宾纷担任设计,我做iOS客户端。
下面将分为技术，产品，协作三个方面来说。
最后做一个对我自己的总结。
技术
毫无疑问，做直播的技术门槛非常大。之前知乎有一个回答，有兴趣可以进去阅读一下–如何搭建一个完整的视频直播系统.
简单来说，客户端需要涉及到音频/视频处理，图形处理，音频/视频压缩;服务器需要做CDN分发，转码等。如果真的从零开始深入，每种技术都够学几年。
以上还不包括即时通讯，礼物系统等社交功能。
好在已经有各个领域的大牛，封装出稳定易用的框架，让我们得以在前人的基础上编程。
直播中，移动端的工作
直播中，移动端的工作还不少。需要兼顾推流端和拉流端，以及礼物效果，弹幕效果等等。
下面简单介绍一下流程，概念。
推流端
推流端，就是主播端。通过手机摄像头采集视频数据和麦克风采集音频数据，经过一系列前处理、编码、封装，然后推流到CDN进行分发。
采集
采集主要为：视频采集，音频采集。
采集到的原始音视频的体积是非常大的，需要经过压缩技术处理来提高传输效率。
前处理
前处理主要是美颜，水印。
美颜功能
美颜几乎是直播的标配功能，它实际上是通过算法去识别图像中的皮肤部分，对皮肤区域进行色值调整。通过颜色对比找到皮肤区域，可以进行色值调整、添加白色图层或调整透明度等来等来达到美白效果。
磨皮的本质实际上是模糊。而在图像处理领域，模糊就是将像素点的取值与周边的像素点取值相关联。有兴趣的，可以看这篇文章实时美颜滤镜。
编码
为了便于手机视频的推流、拉流以及存储，通常采用视频编码压缩技术来减少视频的体积。
现在比较常用的视频编码是H.264。在音频方面，比较常用的是用AAC编码格式。
当然，经过压缩后的视频在播放时必须进行解码。
另外，硬件编码已经成为移动直播的首选方案，软编码处理在720p以上的视频颓势非常明显。在iOS平台上硬件编码的兼容性比较好，可以直接采用，但在 Android 平台上，MediaCodec 编码器针对不同的芯片平台表现差异还是非常大的，要完全实现全平台兼容的成本还是非常高的。
推流
要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。
常见流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1–3秒，对于移动直播这种实时性要求非常高的场景，RTMP也成为移动直播中最常用的流传输协议。
而在网络传输方面全部自己来做太难了，找CDN服务商提供解决方案，其实是最好的选择。稳定快速和专业的服务，可以节省大量的时间。
拉流端
拉流实际是推流的逆过程。
拉流
首先通过播放端获取码流。
标准的拉流格式有RTMP、HLS、FLV等:
RTMP是Adobe的专利协议，直播延迟一般在1–3秒。tcp长连接。HLS是苹果提出的基于HTTP的流媒体传输协议，优点是HTML5可以直接打开播放，通过社交分享出去，用户也可以直接观看直播，缺点是延迟通常大于10秒。http短连接。FLV（HTTP-FLV）协议是使用HTTP协议传输流媒体内容的一个协议。直播延迟同样可以做到1–3秒。http长连接。
三种协议是可以同时使用的，分别用到自己的场景就可以了。
解码和渲染
现在一般播放器都是基于ffmepg的，它是一个跨平台的开源视频框架。
这里有个一硬解码和软解码的概念，硬解码用GPU来解码，减少cpu运算。缺点是兼容不太好。
软解码用cpu来解码，容易耗电发热。优点是兼容好。
秒开
指点击播放后，一秒内即可看到播放画面。首屏打开越快，说明用户体验越好。技术上指播放器解码第一帧渲染显示画面所花的耗时。
首帧数据的展示过程，其实是一个下载，解码，渲染的过程。
GOP ( Group of Pictures ) 是一组连续的画面，由一张 I 帧和数张 B / P 帧组成，是视频图像编码器和解码器存取的基本单位，它的排列顺序将会一直重复到影像结束。简单地讲，I 帧是一个完整的画面，而 P 帧和 B 帧记录的是相对于 I 帧的变化。
如果要秒开，就要减少GOP Cache，也意味着画质下降。
优化策略: 接口机缓存首帧数据，减少 GOP 分片时间，修改播放器逻辑，解析到I帧就开始播放。
我们在这里是使用了B站开源的ijkplayer的框架，它针对直播进行了优化。
服务端
直播是 媒体流 ,而 APP 的交互是 API 信令流，两者的状态不能混为一谈。
尤其是判断网络状况时，不能基于 APP 的交互的 API 状态来判断直播流的状态。
要想适配各终端和平台，服务端还需要对流进行转码，如支持RTMP、HLS、FLV等格式拉流，支持一路转多路适配不同网络和分辨率的终端设备。
CDN
CDN是Content Delivery Network的缩写，即内容分发网络。将网站内容发布到最接近用户的网络”边缘”，让用户就近取得所需要的内容。
负载均衡
多台服务器组成一个服务器的集合，每台服务器具有等价的地位，,都可以单独对外提供服务。
可以将外部请求均匀分配到服务器上，均衡负载能平均分配客户的请求，解决大量并发访问服务的问题。
QoS
带宽管理可以限制每一个组群的带宽，让有限的带宽发挥最大的作用。
产品 and 协作
产品对用户的定位主要是国外年轻的学生群体。因而在产品的设计上也是有所针对。色彩活泼，内容有趣。
中间经历了很多次的改版和思考 : )
关于产品设计
从花姐认真的办事态度，小到一个眼色都反复思考和改到，学习到了很多。然后偶尔有的东西由于技术或者其他等因素，也可以放掉。
关于产品的取舍，不是一两句话可以说清，首先是多用其他人的产品，然后是自己去分析产生自己的看法。
产品需要很多方面的学习，包括设计知识，心理分析，技术实现等等，都需要一定的了解。
运营
产品非常需要运营。这个是我以前没有专门思考过的。就算是真的一匹千里马，也需要伯乐才能发挥它的价值。
公司是商业的，说直白一点，出于什么样的运营其实都或多或少带点销售性质，无论是什么到最后都是作为变现的工具。
运营定位的比较宽泛，如果产品需要内容，运营就是编辑，需要推广，运营就是市场。所以一个产品，一定需要好的运营才能发挥价值。
运营又有:
- 内容运营
- 用户运营
- 市场运营
文档化
把一些关键的信息，进行统一存储在服务器上，简化协作沟通的成本。
- 每日任务说明
- 账号存储
- 测试反馈
- api说明
- 任务记录
scrum保持沟通
每天组织的scrum，了解各个成员的工作计划。需要什么样的资源，确定什么样的目标等。
版本总结。
在重大节点完成后，进行一次大的总结。每个成员，通过自己的角度，评价协作中其他人员不足的地方，针对不足的地方进行优化。
个人的进步
有挑战的工作，驱动进步
在接受直播项目的时候，都还没有毕业，经验有限。
但是一整个流程走下来，学到了很多东西。主要谈学习的方法，具体的技术点更是数不过来了。
总的来说有：
查看issues。工作中大量使用第三方库，直接去开源的项目下看issues,会得到很多有用的信息。参与开源，发起pr。对使用到的饿了么网络库/来疯直播推流器/leanCloud的ChatKit，发起pr并被成功合并 : )自动化流程尝试。由于频繁的打包，尝试用python脚本自动编译打包，上传到fir.im发邮件通知。并进一步了解到Travis CI，能做初步使用。热修复技术的使用。因为缺乏足够测试，总有些小问题，但是发版的时间成本太大，就学习了JSPatch的使用。响应式编程了解。针对繁琐的业务逻辑，相对于面对对象，响应式编程更有优势，同时尝试mvvm的学习。以及了解RAC，和学习rxSwift。调试技能。学会使用一些lldb命令，进行调试，输出视图层级，查看崩溃调用栈等;学习了解到instruments，学会检测内存泄露，让代码更加优化等。
思想的进步
- 保持成长—交流发现了各个领域的牛人。对照自己，还非常的年轻和不足
- 协作的认识—产品不是单靠技术，需要各个角色一起完成
- 严谨的思维—做产品，第一还需要理解产品的思维，和逻辑。针对各个情况，代码上进行处理和折中取舍等。