千帆直播APP从诞生到现在经历了4个大版本，分别定位于“可用”、“完整”、“全民直播”、“高端大气”，在搜狐生态下创业的过程中，千帆直播从求生存到求发展，在有限的资源下，冷静的调整自己在搜狐生态及直播平台领域中的定位和策略。不断完善团队研发体系、技术选型和重构，有节奏的增加和优化美颜、打赏、耗电、网络技术调优等。
千帆直播孵化历程
我首先还是做一下简单的介绍，搜狐千帆直播项目从2015年的7月份在广州开始立项，这个项目是隶属于搜狐视频的子公司56.com，我们花了三个月的时间，在2015年10月份正式上线。紧接着我们做了第一款APP，后面我们会讲APP的敏捷开发的过程，一些里程碑事件，包括2016年上线的手机端开播，2016年的5月份新的UI，再后面做了VIP直播间，包含一些新的、炫的效果， 2016年10月份，千帆直播一周年时每天大概有一千多主播同时在线，还是一个比较小的团队。
今天我受邀请来和大家分享一下，一个比较小的团队怎么去做敏捷开发。
产品定位
第一个问题就是做一款APP的时候，你的产品怎么去定位？创业的团队首先想的问题是我的产品定位什么样的用户群，涉及哪些核心的功能？
- 流量入口：直播是现在一个热的风口，人气很旺，受关注度高，我们首先定位成一个流量的入口。
- 全民直播：拿到流量以后的话，干什么事？或者是说你的流量怎么消费掉，我们把它叫全民直播。
- 易用：APP涉及到一个最基础要求就是易用，APP足够的轻便，足够小。
- 赚钱：作为一个创业团队，虽然我们是集团公司内部创业的团队，也有KPI；这个KPI涉及到赚钱，怎么样能够养活这个团队员工？团队什么时候需要去扩展？我会继续跟大家去分享一下，一个小型的团队怎么去赚钱？
客户端
作为一个APP，需要标准的适用于iOS和安卓平台，这些都是必须需要有的基础的配置，还有在分享的闭环里面，需要用Html5去传播。
在搜狐的平台内有这个特点，可以帮助独立的APP壮大。比如千帆这个项目它的初创时用户量很小，为了获得流量，我们自己会打包成一个第三方的SDK，去集成一些大的一些应用里面去，比如说搜狐视频客户端、或者搜狐新闻客户端等。
但是搜狐集团又是一个庞大的企业，千帆这个项目比较小的时候，大公司里面要生存下去，首先得知道你在公司里的定位，我们首先要找到自己内部供应商在哪里。千帆这个团队，找了集团里面的支持，比如说搜狐视频APP提供的流量入口，提供编码和解码技术。
然后找搜狐集团的CDN的团队、钱包、通行证，基础运维等支援。我们团队到目前为止才60个人，技术团队就更小了，这样一个小团队需要借助更多的集团资源。
在第三方这块就是比较成熟的一些模式。比如充值，不会自己去做充值，于是借助第三方成熟的方式， 比如支付宝、微信、银联、PayPal。
CDN供应商方面，我们也用到了一些比较好的合作伙伴，网宿、金山云等。
千帆直播APP release进度
这是我们APP的Release进度，采用敏捷开发的时候，一个版本怎么样去控制？基本上我们每个月都会有一个小版本和一个大版本，这个图上每一个点都是我们一个安卓版或者iOS版的Release的时间。接下来我想跟大家分享一下，截止到目前位置，我们这个APP做的几个里程碑式的版本。
可用的秀场APP
在2015年10月份我们上线的第一个版本，我们把它定位为PC上的套壳，因为我们首先花了三个月的时间做的是一个PC的业务，APP上做的第一个版本，它只是一个简单可用的一个秀场类的APP，包括的功能有首页，分类列表，有直播间，个人空间，聊天室等，一些简单的工作花了两个多月的时间就做出来了。当时安卓团队3个人，iOS团队3个人。
完整的秀场APP
我们在2016年春节前后做了第二个版本，大家知道做秀场类的直播是看中游戏和互动的，我们在春节前后，我们做了一个新的版本，这个版本里面就加入了一些简单的互动版本，包括红包、贡献榜之类的工作。直播间的红包 和全站的红包，我们希望借此将陌生人转化为粉丝和熟人。有了红包，气氛就活跃起来了，跑骚的队伍都晚期串串龙游戏。
我们又做了一个简单的游戏，叫做挖宝。为什么会选择挖宝这么一个游戏？大家都买过彩票，每个人都梦想着有一天可以中个大奖。在一个虚拟的场景下是一样的，玩家们也想在消费虚拟礼物之余，来电探索类游戏。当面对几个宝箱时，用户会忍不住去点击一下。这个挖宝产品实际上就是一个让更多的人感觉到有机会去中奖，你会发现这么一个小产品会促进用户的消费，在清明节前后的时候，我们做了一个简单的改版。
全民直播
前两个版本还是一个传统的PC应用，给它套了一个APP的壳。清明节的时候，我们在这个APP上增加 “开播”功能。
5月份的时候搜狐做了一个明星首秀，我们迎来了这个APP里面第一位大咖级的人物，这个中间的大叔是互联网的主持人邱启明先生，右边的这位美女是《欢乐颂》其中的四大美女之一，叫乔欣，那个时候会发现这个APP做得还是比较Low的，它里面只有一些简单的互动，发言，还有一些数据。再往后，我们往敏捷方面去推进。
高大上
5月份，我们又会做了一个新的改版，加上了大家常见的一些玩儿法，比如说推荐，加上了一些深度入口，准备搜狐集团的业务进行合并。
6月29号，搜狐千帆直播项目在集团内迎来了它的发展的机会，图片左边是张朝阳先生，是我们搜狐的创始人、董事长，右边的这些是他和明星们去参加了一个“搜狐名人马拉松”活动。千帆直播当时是一个配角。
到了10月份，千帆直播从一个配角变成了一个主角，左边的这位依然是张朝阳先生，右边的那位，有人认出来了吗？他是大家熟悉的小齐（任贤齐） 。我们已经从一个简单的秀场的直播成为一个产品宣传渠道，作为一个流量入口这样的产品。
音乐版
是不是要集成音乐，我们需要去做音乐上的一些配置，主播们在开播的时候能够去找到自己喜欢的音乐，来做背景音乐，于是我们决定做一个音乐版APP。有不少人做过音乐盒，音乐的播放怎么去控制，怎么去降低声音的误差，怎么去做歌词的校对，这些都需要去把它集成进来。
敏捷定位
关于敏捷开发，今天给大家分享一个小团队的敏捷开发的过程，很多同学是做开发的，所以应该知道，敏捷开发有18条军规，里面有很大一项是关于会议。
- 三地沟通：首先是团队，因为我们是三地办公的团队，广州、北京和天津，我们还有很多的供应商，前面讲了，包括CDN厂商、技术服务供应商等。面对这么很复杂的关系，团队规模不是很大，又分布在不同的地方，考研敏捷沟通是不是做得足够的好？我们团队里面，为了保证三地沟通，基本上每天都会有四到五场的沟通会，每次沟通会绝对不会超过30分钟。
- 测试包频率：一个APP，打包的频率是多少呢？好像很多人事一般一周打包一次，我们内部的话，是要求测试包每两天打包一个。
- 小版本迭代：要求十个工作日，也就是两周的时间可以打包一个小的版本。
- 大版本迭代：不超过30个工作日。
- code review：我们需要去做不停的去做code review，安卓的团队，需要每一人都会去做代码review，iOS的团队还会执行交叉。
- Q/A报告：测试组的报告是保证你的APP体验，减少APP出错率的一个很重要的指标，测试的报告一定是要每天都有。
- show case：这块我们要求全员参与，我们公司里面不论是我，还是产品、开发和测试同学都要去参与到整个APP在Release之前的show case的工作。我们习惯性把大家关在一个黑屋里面，每个人去体验产品，是否达成了计划。
- 灰度的测试：APP在上线之前都要去做灰度。PC上常用的一种说法就是通过哈希算法，把一部分用户哈希在我们新的版本上去。大量的用户跑在老版本上，这样对新版本的体验，及时检查一些数据是否准确。APP也要去做灰度，比如说安卓的发布渠道有那么多，你可以先只发自己的官网去了，让用户有一个体验期，给技术一个改善期。然后再组装到其他平台，比如华为市场，应用市场等等。原因是APP端有个特点，就是APP在Release之后很难去收回的，也不会强制用户去升级。
多版本作战
我们研发的团队一般都是在多个版本同时作战，我们4.2的版本正在做维护，4.3的版本正在开发，4.4的版本又在做调研，这个时候，你的团队人很少，我们只有四个人或者五个人的时候，怎么样分布时间管理，把核心的工作、核心的精力放在新的产品的开发和调研上面。
还有关于针对某个功能去打的版本，比如说我们针对的一个特定的新闻场景，需要去打一个横屏版；针对特殊的主播产品需要去打一个音乐版；还有应用宝的这种定制的版本。这样有多个版本出现的时候，研发组织结构怎么去控制呢？一般的节奏就是根据你的功能的紧迫性去实施。
关注的细节
前面讲的就是关于我们产品进度，接下来我想说下细节。一个小的团队，你要把一个产品做得细，细到什么样的程度？一定要自己去体验，我不知道有多少人会每天用自己的产品。我基本上对自己产品用到了又爱又恨的地步。
张朝阳先生，他关注这个产品之后，他也用起来了。但是我们发现有一个Bug，就我们每天的9：36分数据会闪断，为了揪出这个Bug，我们整个这个研发团队可能花了一个多星期的时间。一边要保证新产品的开发进度，一边又要去调试这种偶然出现的Bug，去找到它对应的问题在哪里。
还有一些细节性的东西， 比如看很多人用APP分享到朋友圈之后，他的朋友从朋友圈进来的时候。我们一般走微信的授权登录，授权之后会显示用户的真实的姓名。我觉得可能很少有人会关注到这个问题，就是当一个主播他看到他一个真实的朋友进来了直播间，也许那个人可能就是他的父亲或母亲，这时候他会觉得很别扭，所以呢，当用户会把这个信息反馈到我们时，我们会立刻意识到问题严重性，并马上付诸实施。
核心功能
我还想给大家介绍一些核心功能的优化，我们自己一步一步踏出来的坑，我觉得需要去跟大家去分享一下。
如何提升开播成功率
大家拿着手机，给自己拍视频的时候，或者拍照片的时候，你会发现这个成功率是非常高的，很少出现打开摄像头崩溃的现象。 但是当你去打开手机APP想去做个直播的时候，是否一定能直播成功呢？ 在技术的后端，这个成功率是需要很多手段去保证的。
比如说我们上午也在讨论这个话题，当一个用户在他自己的网络下面去推流的时候，推到哪个节点上去，或者是说昨天推流的节点今天是不是还能用。 实际直播过程中，发现了很多错误。比如说主播上午还能用，但是他下午收到一个提示，推流不成功了。这个时候APP需要去做更多的一些保障。比如说使用多套CDN供应商，通过完善的A/B互备方案，去保证推流的成功率。
第二个问题就是关于线路的择优选择和择优记录，这是我们跟CDN的朋友一起去踏了很多的坑才去实现这个工作。探测和动态码率，也就是说当主播在上行的时候，它的码率是一个恒定的，还是一个动态的。在主播推流上去的时候，我们会动态的计算网络速度，去调他的码率。如果条件比较好，各种计算资源足够的时候，会优先保证它的帧率和码率。当出现波动异常的时候，去降低帧率，降低码率。
还有一些关于你开发的技巧，手机上的CPU计算能力优先服务给谁，比如说当观众进入直播间的时候，CPU优先做画面渲染。
如何让美女更美
我们下面看到的手机直播上的这些美女，都是形象特别的好。可能很多人不知道，看起来很美的这些视频都是“假的”，所有你看到的美女都是通过计算机程序计算出来的，包括了大量的美白、磨皮、美光这样一些参数的配置。比如说我前两天就学到了一个化装词语叫做卧蚕，我们把它应用到美颜算法里，这是个很复杂的工作。我们工程师反复的沟通和修改算法，然后让美女看起来更美。还有个话题，让帅哥更帅。所以我们在针对男主播和女主播的算法上是不一样的，在亮光的环境下跟弱光的环境下也要去做得不一样。
观众是上帝
观众这一块，我们一直保持着谦卑，谨小慎微的态度。努力去服务好每一个观众。比如说我们上午还在讨论这个问题，观众的到达率是一个很头疼的的话题，为了保证一个观众能够打开并且能够快速的打开，我们需要去准备多个文件备份，比如你说需要去换多个CDN厂商，上行和下行是分开做，码率也是一样。
观众这边，如果所有的观众都看的是同一个码率，并不能保证它就很好。一般的情况下，比如说我们做到450Kbps码率，甚至有些观众我们可能只给他降到200Kbps码率。为了保证观众的这些服务，开发的人员还要去干很多很头疼的一些测试，比如说推流用RTMP协议，拉流是不是还继续用它呢？还是说我们要去换一个协议？
观众如果他正在观看直播的过程中，忽然来了电话，来了个微信，他去切换，他需要怎么去做？如果观众从一个在马路上走进入大楼切换到WiFi的时候，信号是不是要中断？不中断的时候怎么样去重连，这些话题我觉得都是需要我们开发的同学去思考的。
比如说在这种情况下，当用户从一个4G网络切换到WiFi的网络时候，有可能是它在外面是拿着移动的4G卡在看，然后进来之后是联通的WiFi，这个时候我们怎么无缝的去切换，这个开发的同学费了很大的劲。 还有一种可能更麻烦的事情就是观众在移动的场景下频繁的换网，比如说进电梯没信号了，出电梯又有信号了。技术上为了应对，需要去做一定的缓存。
卡
下面一个我想介绍的是“卡”，这是直播平台的生命线。当用户在平台上面的时候，会无缘无故的去抱怨一句：又卡了，卡飞机了，这怎么这么卡？有时候用户的这种抱怨会很快的传染出去，一个人的抱怨会传染给很多人，一些偶尔卡顿的用户，也会不停抱怨卡顿，把问题放大化了。
同行内，有人专门写过分析文章，说有一秒的卡顿会损失多少钱？一分钟的卡会损失多少钱？
我们没有确切的数据来衡量损失的钱数。但是技术的同学要干的事情，就是消除卡顿。消除卡顿的第一个任务，要弄清楚到底是什么卡顿。
视频流卡顿，用户打不开视频流。
消费的行为卡顿，比如说像陌陌的同学讲，一秒钟的定单达到了一千单的时候，用户下单很卡顿，这种情况下，应该怎么去做？视频流很卡，不停的去切换它的调度，找到最近的一个节点去服务。还有，如果用户实在是很卡，而且又是一些我们的大客户，我甚至给他单独测一下，给他做一个单独的线路。如果用户抱怨的是消费行为的卡，用户下单下不了，这个时候我们经常去干的事情是找到更好的线路，或者我们加了几套用户方案，比如说我们常用的一个IDC的解决方案，可能会导致卡顿，那我们会换一个供应商的域名解析方案。
然后我们的服务端的架构要支持水平扩展，当你在某一种消费的行为出现了这种瞬间的峰值的时候，需要去做一些服务的扩展，去解决这些卡顿的一些情况。
我通过这些方式，不能完全的去消灭卡顿，但是我希望能够降低用户的抱怨。
回来再说主播的情形，我们的安卓的设备实在是太多了，上一次我跟大家分享，是说我们能够覆盖到Top 20的机型，但是现在的情况是Top 20机型也在不停的去刷新自己的江湖地位，比如说大家看到现在OPPO的手机已经非常的厉害，OPPO的手机在我们的平台里面的比例也非常的大，甚至奇酷这样的手机占比也非常的大，针对这个手机，我们需要去单独给它设定一个码率。
这张图里面前面第一个画的就是，我针对华为的手机，我设的码率是500 Kbps，但针对OPPO的手机，我把它设到450 Kbps。上行的时候码率还要去调整。还有针对不同的主播去开启不同的功能，比如同样是我们一个家族的主播，同样是在北京，但是我给它的链路还是不一样的，这个时候需要不停的去设计，需要去关注你的主播和一些体验。
优化之路
前面的话，我们讲了一些关于敏捷的实验，我现在还想跟大家分享一下就是一个APP在优化的时候，还有哪些工作可以去提升的。
- APP的开启速度：我们上一次也讲了怎么去提前做APP的解析。当用户进入到APP的时候，先把它解析到将来要用的那个流文件的地址去，然后给它做提前的域站，调试GOP等一些策略。我们一直在干这个事情，就是拿到什么就播出去，拿到音频就播音频，拿到视频就播视频，减少对视频关键帧的依赖。
- 提升流畅率：流畅率这块也是非常非常头疼的，目前为止，我做到了一部分，就是去加一些解码的缓冲，统一做了一些选择性的丢帧，在优化这条路上，真的是走不完的路，技术这条路真的往后面越走越麻烦。
- 肾6开播不流畅：我们看到的iPhone6和iPhone7的直播也在不停的优化。主播偶尔抱怨说开播不流畅，或者播了一会，手机已经烫的不行了，恨不得把它扔掉。播着播着，突然间系统弹出提示空间不够了等等，都影响到用户体验。
- 手机的流量：很多主播在用移动网络去开播的时候，在没有做直播之前，1G的流量足够用一个月，但是他用手机去开播的时候，三个小时，四个小时流量就没了。降低主播流量的消耗，或者补贴主播的流量，都是需要继续研究的课题。
- 移动端劫持：比较麻烦的就是移动端的劫持，相信我们所有做过开发的同学都知道，用户的网络是经常会被劫持，被劫持到哪去也不知道，什么时候被劫持也不知道。
HTTPDNS是不是一个解决方案呢？我们之前也做过一些测试，但是它并不能够做得很彻底。
目前为止，考核方法就是去不停的去监测。一个很小的团队，你要把这么多事情都做好，太难了。我们还会去干很多事情，比如又设计了一套A/B互备方案，当用户访问APP的时候出现数据错误，比如说三次重试之后，我们切换到下一方案上，试图用此方法去解决这个劫持的现象。当然最近也有供应商跟我们谈，可以换一些VPN的线路，这也是一个不错的方案。一些长期被劫持的用户，以及重要的用户，给他使用VPN解决方案。这个事情也要考虑成本，太贵。
还有APP的大小，一个比较理想的是安卓一定不能超过20M，iOS控制在30M以内。
有一些大主播，在户外直播时候，他会经常遇到网络不稳定的情况，我们自己去做了一款网络盒子工具。这是什么样的场景呢？就比如说我们的主播漫游到其他的城市，会出现他带的那个移动的网卡已经不好用了，比如说到台湾，中国移动的这个卡到了台湾只能打电话，上网都上不了。主播必须租用当地的线路。但是如果去的人太多了，管理的成本就会扩大。
于是我们做了一个网络盒子，它可以支持多个运营商的网卡，甚至漫游到世界上其他国家都可以支持。今天我也带了一个，这是我们自己做的网络盒子，这个盒子就是能够满足，当主播在户外的时候，挂多个运营商卡。当一个运营商的线路不好的时候，可以自动的去切换到另外一个运营商上去。
动画好才有消费的欲望
后面是关于APP端的一个消费的场景，所有做产品的，一定会想着我这个产品做出来，不仅是为了做一个功能，我要做的是消费，我要如何活下去，就像公司里面每一个部门，在考核的时候都会说，我们的KPI是多少，完成了多少。
千帆APP运营的KPI里，也包括了刺激用户的消费。我这个话题里面只写了，动画好才有消费的欲望，还应该说是套路深才有消费的欲望。
从技术的角度来说，我们需要去做好更多的一些动画的效果，比如说图片格式用WEBP，礼物需要去做成连击的效果。让观众操作起来很便捷，这个便捷性体现在哪里？一定要支持一个手就能够把事情给干好，而不要是说左手拿着手机，右手去操作屏幕，这是我们在做产品体验上的一个指标。那大礼物，比如说什么样的礼物是大礼物？比如飞机，这个东西你要把它播放，可能要播几秒的一个，是大礼物，那大礼物在播放的时候不要去一次性的把它播完。
我们项目里面还做了一个产品的逻辑叫爆灯，爆灯的意思是说，当用户积攒的流水达到了888的时候，突然会有一个爆炸性的效果，让整个空间里面放烟花的效果，这种效果会刺激更多的人去消费，所有的消费者为了保住这个灯不灭，需要去不停的去刷礼物，主播也会需要去调度，说白了就是一个套路。
技术展望
前面我跟大家讲的关于产品，关于一些优化的事情，我觉得今天是一个比较开放的一个技术讨论话题，所以我还想提一下未来的一些事情，虽然这些事情我们目前都还没有做。
- 一个团队里面的，一个很小的团队，你是否要去做标准化？怎么样去定义模块和代码重构的周期。我们团队做得比较弱，我们甚至都没有做标准化，我们只是做互相code review，我们要求每一个工程师写的代码，另外一个人也能看懂。我们没有去做更多的标准化，因为我们觉得敏捷开发也很少去强调标准化。
- 关于未来我们是不是要全栈HTTPS，从HTTP 1.1升到2.0，我们还需要尽快的去把这个HTTPS迁上去，我觉得有一些不安全的因素存在的。
- 我们很多人都觉得直播的带宽很贵，是不是要做P2P？做点播视频的同学都知道P2P当年的分享率达到60%的时候，带宽消耗会下降一半。所以我们什么时候需要去做直播P2P？APP里做直播P2P的技术门槛有多少？这些都需要调研。
iOS
iOS基本上很多APP开发的时候都是多位一体， 千帆直播支持了iPhone，但是不支持iPad。有人说这是一个比较糟糕的现状。我也常问自己，是不是要去做iPad的兼容呢？这个话题困扰我很久，我估计每个创业的团队都会遇到这个情况。
Android
关于安卓，我们支持TOP 20机型，但是这个江湖的排行榜也经常变，有人下去就有人上来，那上来那个我们需不需要去做支持，什么时候支持？是延迟一个月还是延迟一周？安卓版APP出现Bug之后怎么去修复？
产品展望
关于直播这个领域，我们还有很多可以去干的事情，就今年特别火爆的VR这个事情，我估计很多产品都去尝试过，直播VR主播如何使用，接VR后的消费产品怎么去设定。我们曾经也干过这个事情。在奥运会的时候，做了一个环形的演播厅，挂了一套VR的设备。看起来高大上的产品，但是用户根本就不埋单。是什么原因造成的？我们一直在反省这个事情。
然后关于直播，是否要进入一些垂直化的领域？我先问自己，我们擅长干什么？我们擅长干娱乐的事。那我们是否可以干体育类直播？我们是否要去碰一下教育类直播？不要停止思考。
