摘要: 近两年，直播业务爆发式增长，出现了大量做直播业务的企业和团队。其中，移动直播更是百家争鸣，风光无两。这时，各家的产品及业务优化将很大程度决定市场的认可度和口碑。移动直播技术要如何优化？团队要怎么高效研发？来听听大咖怎么说。
刘恒兵（河伯），腾讯前端技术专家，IVWEB 负责人。现腾讯互动视频业务前端 TeamLeader ，互动视频、NOW 直播 Web 负责人，负责互动视频前端整体架构设计和开发。多年 Web & H5 移动开发经验，对移动监控和优化有深入研究，同时推动组件生态，致力于打造高复用、高效率的全栈开发体系。OSC 源创会第55期广州站讲师。
一、直播业务的变革
1、直播业务发展
直播业务最早开始于2013年，当时是社区，功能只有简单的语音聊天。随后，YY做了很多从社区转向娱乐的事情，掀起了在娱乐直播行业的一股小高潮。后来，大量的传统媒体和一些有粉丝体系、名人效应的传媒介入以后，直播转变为基于PGC的一个体系。这个阶段的大部分平台基本偏向于专业做直播这一块业务的企业在做，业务质量会相对高一点，那时的行业增长达到了300%。再到后面，发现广大用户也有直播需求，这个真正带动了基于社交的直播。
2、直播业务变革
随着直播业务的快速发展，给技术人员带来的挑战是什么？技术人员要怎么应对这个业务带来的技术上的变革？
首先，从原来简单的直播，到细分娱乐直播、游戏直播、体育直播等等，再到用户的实时直播，直播场景在不断细化，导致涉及到的技术方案也有一定差异。随着环境复杂度的变化，网络场景和用户场景越来越复杂，技术人员需要考虑各种细分的场景，以及各种极端的情况，而不仅仅是平均值。同时，硬件的成熟，给技术人员带来了更多机会，以前做不出来的效果，随着机器性能的提升逐步实现。网络条件的成熟，4G/WIFI的普及也让直播变得更为流畅。但是，技术人员也需要用更新的技术来满足用户的诉求。
3、产品体验变革
随着硬件和网络条件的成熟，用户对产品体验的要求也越来越高。以前的产品主要在PC端，大家只要集中精力把PC端的产品体验做好闭环就行，放到移动端可能玩不转。很多移动端的体验是基于手机的单屏模式，而且用户很容易切出直播界面，比如突然来了个微信消息，要切换过去看。这给技术人员带来了和PC端不同的挑战。也就是说，随着移动端的发展成熟，除了技术，产品体验也在变，这就决定了很多技术方案和技术细节需要不断地去变化。
4、直播技术变革
综合来看，对于技术上带来的挑战就是：
对性能有更高的要求：比如以前可能只要20%的用户有好的体验，现在可能要达到90%以上的用户有好的体验。
低端设备更高体验：低端机并没有消亡，如果有看移动端的基础设备统计会发现，低端机一直存在。企业若不愿放弃这部分用户，就至少需要能让他们有降级的体验。
用户等待容忍度降低/弱网络良好体验：用户的等待容忍度在不断降低，以前用户会认为自己机器不好、网络不好，可以等待加载和延时，但现在他们会认为是业务体验差。这时若有其它产品做的更好，你的产品就会被卸载，技术门槛就体现在这里。
互动性、实时性/流畅的交互体验：直播行业对于实时性和互动性的要求会非常高，主播在直播时如果无法及时得到观众的响应，体验会非常糟糕。
二、直播极限优化方案
1、深入掌握极限优化
挑战已列出，接下来就要想办法解决。极限优化这个概念，不同的人可能有不同的理解方式，但最终的目的是一样的，配合业务做好体验。
首先，得清楚优化的使用场景，最终是要解决什么问题，是用户的体验问题？还是性能问题？亦或其它，不能闷头行动。而且，优化方案带来的实际提升要有预估，根据投入成本进行预估。
同时，要深度分析优化方案的可执行性。因为优化往往不是一个人在做，而是一个团队在做，如果方案本身就不可执行，那浪费的是一个团队的时间。而且，要找准关键的点在哪里，根据自己业务的瓶颈来做，不要盲目跟着别人的方案来做。事先清楚和找准后，再去进行深度的方案讨论。
然后，是要尽量避免过渡优化。怎么理解？在做优化方案的时候往往会有很多很多方案，有些提升的比例可能没那么高，比如从98%提升到99%，但带来的人工和维护成本非常大，这个时候就要考量用户的比量，确定是否值得投入。
2、常见优化方案
每个团队所用的技术、方案都不太一样，所以在优化上面也会有所差异。在此，针对常见的3种方案进行优化分析：
前后端分离：最初的大部分的业务应该都是前后端分离的方式，前端就聚焦在前端上面，后端专注于后端的一些接口、数据的调用。这时要怎么去优化？首先，随着业务越来越复杂，前端要做分层处理、模块化，以便维护。同时， 要重点做前端资源加载的优化，因为后端只是在做数据拉取，只要能够抗住量，就没有太大问题。而且，要清楚每个资源、数据在异常情况下带来的影响。举个列子，你的业务可能有很多很多的资源，当第一个资源失败，会带来什么结果，第二个资源失败，又会带来什么结果，这些都要非常清楚。否则，当用户把问题反馈过来时，很难第一时间发现问题所在。此外，网络场景要去细分，了解用户的重点是在哪里，是在4G网络，还是在WIFI网络，优化重点要进行偏重。
重前端MV：随着前端的发展，前端MV框架愈加常见，很多业务、团队都有在用。这种情况下的前端更重，就需要考虑前端并发，不能让用户去等待很多很多的信息。同时要去做同步渲染降级，让用户快速看到。还要考虑在业务里面的SEO，对于浏览器来讲，当它拉的信息都是一样的，它会认为页面的更新非常低，搜索引擎很难抓取并更新。
Node全栈研发：在发现诉求越来越多的时候，就需要有一个能同时聚焦到前后端的工具，刚好Node就能帮我们做很多事情。这和前后端分离有点像，但又不完全一致。可以看成，前者是前端一个人后端一个人，但更好的情况是能前后端只有1个人，这样他会更清楚前后端的逻辑，而且这些逻辑要尽可能的在前后端复用，这个时候就要考虑前后端的复用体系。Node本身很强，但还需要注意更深入的一些东西，比如TCP/UDP协议的解析。因为你后端的数据是来源于它的后端的一些数据调用，如果这个时候能够用node解决，那是最好的，前提是node能撑住这个量的场景。
3、效率至上
优化的同时，要对团队的效率进行掌握。效率至上来做优化，才是合理的。对于效率，可以从以下几个方面去看：
第一个是刚才讲的复用体系，前后端复用体系怎么去复用；
第二个就是需要有完整的构建工程体系，现在其实有很多构建工具，在此不做列举，能用工具解决的事情都不要去用人力去做，哪怕是一个简单的更改。因为工具解决不会出问题，但人力解决难免会出问题。
第三个是需要有完整的研发技术栈，研发技术栈决定了团队的统一性，能够帮助新人快速融入和业务的交接。
4、研发生态
虽然说效率至上，但也不能只讲效率，还要有所有工具体系的一个生态闭环。它能不能自动更新、自动维护，能不能有一个方式去迭代。比如说其中的一个组件，它可能会升级、会改变，升级的方案是什么？升级后怎么快速的能够跑起来、用起来，不出问题？这就是生态，生态会有很多方面，把业务里面的生态建立起来后，团队的优化才是最高效的。
三、直播优化实践
确定了方案，下一步就要应用到业务中实践。同样，每个业务的情况都不一样，这里还是以直播的业务来举例。
1.1、监控——加载监控体系
首先，要知道你的业务瓶颈，这就是通过业务的监控分析出来的。没有监控是很难知道业务的瓶颈在哪里。那到底要监控哪些点呢？可能有人会比较茫然，那么多业务，哪些点是重点，哪些点是必须要做的点，难道每个都要监控吗？
在此，列出了在业务中需要做的点：
不管是从资源的加载，还是资源的使用，还是版本的覆盖，还是本身的前端的错误，这些都是要做的。如果这些都没有做，那么说明对业务的掌控是不够的，你不知道用户哪里出了问题。所以说监控是很重要的点， 现在有很多开源工具可以帮助你去做，也有很多现成的统计工具。
当然，监控不是最终目的，优化业务和提升业务才是。工具做好之后，就要去在监控中发现问题，最好是能主动发现问题，而不是被动的依靠用户投诉。
1.2、监控——视频流监控体系
在直播业务中，还有个很特别的东西就是视频流。因为它的特点是量很大，加载对用户的网络要求很高，在视频上面对视频流需要比传统的资源更细致的处理。需要去从它的加载、播放等各个方面做监控和完善。做完这些你才知道你的业务问题和瓶颈在哪里。然后再经过分析，就能知道要从哪里下手进行优化。
1.3、监控——机器性能指标监控体系
同时，刚才也有提到，业务对机器的性能要求越来越高。有很多的机器甚至可能根本没办法支持很高的FPS业务。性能对业务的影响非常大，同样的性能，A业务能跑起来，B业务如果跑不起来，用户的感觉就是B业务做得烂，团队很差。性能能够帮助建立业务的影响力和用户的口碑。
对于性能，其实也有很多办法可以去做监控，比如说给业务在机器上做性能的评分，通过评分能够知道机器到底是什么情况，用户的机器到底能承载多少FPS业务，再根据结果进行降级和升级优化。这就需要统计和分析用户到底是处在什么样的机器性能什么。还有给不同动画进行FPS归类、针对资源分类打包等等方式，都是监控性能比较好的方式。
1.4、监控——前端日志监控体系
刚刚也有提到，用户的环境非常复杂，这也是为什么说做前端要去细分到每个用户的原因。不像做服务端，机器上跑什么版本你是知道的，搞定这个版本怎么做就ok。但用户不一样，每个用户都是不同的，出了问题不一定能知道。在大量的数据情况下，是需要测试才能测出来的。因此，要对用户的实际情况进行监控，到底业务走到哪里了，没有走到的原因是什么？将这些信息全部收集上来。
2、监控体系的自动化
有了这么多监控方式，自然希望说它们能够自动化去处理。仅仅依靠人力，每个业务上线都去弄一遍，那很难跑下来，人力成本会十分恐怖。因此需要去做自动化的处理，能够实时的知道业务出了问题，问题出在哪。而且希望能够通过一些前端的染色，毕竟用户的网络其实也是有成本的，什么都上报，流量费用比其它业务高很多，用户可能会进行投诉，这就需要染色的能力。染色的能力就是说通过配置server去抓取你想要的用户出错信息。
3.1、业务优化实践——节点、场景优化
有了这些自动化之后，就要开始实践了。在业务中去实践的时候可以看到，一个页面的加载会分为很多流程。这些流程下面就是需要去针对细化的各个节点，并确定每个点到哪一步需要什么优化方案。还有在各种场景的细分和划分，针对这些场景进行优化。
3.2、业务优化实践——移动页面性能优化
对直播业务来说，移动端的业务量非常大。因此要学会充分利用性能工具来做事情，学会用工具作分析。同时要关注CPU变化趋势和GPU渲染能力。如果说实在通过H5已经解决不了问题了，就要适当去找你的环境，环境会提供很多native的能力，不管是用React-Native还是用原生native接口的方式，都只有一个目标，就是通过环境来帮助你业务可以更好的体验。
3.3、业务优化实践——图片资源优化
在直播行业，有两个资源比较重要，一个是视频，一个是图片。先看图片要怎么去做优化。
图片其实有很多很多方式可以做，首先要考虑用户的情况：第一，这个图片能不能快速的加载下来；第二，这个图片在用户端能不能快速渲染。这些决定了图片在业务上打开的快慢。
3.4、业务优化实践——视频资源优化
在直播行业，通用的视频架构几乎都会包含下面这些模块，每一个模块在处理时都需要时间，而最终都会体现在影响用户体验的时延。主播开始直播，从上传视频源的这一秒开始计时，到用户能看到主播说这话的这个时间段就是时延。时延是直播业务非常重要的参考数据，时延太高，互动性会非常差。
举例来说，主播开播，那他就是视频的上行，从上行的开始，要去申请很多很多流程，同时要把这个视频流做一些格式的封装和解码，这就需要处理时间。同时，视频资源比较大， 不能以普通的服务器来承载，要用CDN这种方式来承载，这时流的传送也是一个时延。
在下行端也一样，CDN的架构会有很多很多的云，用户接入时候需要从异地云上拉取资源，这也有时间等待。这里面的时间最终会体现在用户的拉取时延上面，打开视频，可能要等3秒、5秒、10秒。
视频要怎么优化？互动时延和加载时延的问题要怎么解决？
直播业务里面有一个比较关键的数据——GOP关键帧，就是一组动画关键帧。在播放器播放时，是按关键帧解析，非关键帧无法独立解析，必须依赖关键帧才能去渲染。在移动端H5的播放时需要3个HLS分片，分片是关键帧在服务端经过转码之后打包后出来的。因此，要解决互动时延的问题，其实就是优化关键帧的间隔。比如5秒一个HLS分片，3个就是15秒，那主播说一句话，用户要等15秒后才能听到。加载时延就是上面提到的流的分配，能不能优化主动去push到这些节点而不是等用户去拉取。而且上行很多时候是不稳定的，更需要去做很多很多处理，假设丢包了，很多画面解析不出来，这时候还要补帧。
另外就是回放，回放和直播唯一的不同是不需要互动性，主要需要优化加载时延。这涉及到另外一个概念，就是MP4的格式。MP4是按个块封装，可以理解为一个一个的指针，指针的位置是需要相乘，MP4的文件头需要下载下来才能播，如果指针的信息越来越多，索引越来越多的话，不利于加载，这就需要在服务端处理。
四、直播高效研发之道
前面既然说了这么多需要做的优化工作，那自然是希望能够不用每个业务都去做一遍，这就需要去做一些研发效率方面的事情，帮助技术人员快速去做这些事情。
研发效率怎么理解？首先需要有完整的构建体系。这个体系里的工具是根据业务的特点来选择，没有好坏之分，没只有合适之分。同时，需要组件体系来管理组件，你的前后端复用最终都是要以组件的方式存在，组件可以把业务分解到非常细的密度，利于更好的复用。在组件的使用上面需要更快捷的使用方式，上传、更新以后，在需要的时候能快速更新到业务里面去。这些所有的其实都是基于技术栈的统一。
体系建立以后，怎么在业务中使用呢？
业务组件分两种：一是基础组件，就是没有业务区分、通用的，这种不涉及逻辑，只有UI组件，使用的时候可以直接引入UI组件。二是业务组件，需要去做合理的拆分。通常的直播间要拆分为很多很多点，视频、点赞、送礼等等。拆分后如果以后有业务不需要点赞功能，把点赞组件引用去掉就可以，这样就能快速组成新的业务。在引用的时候有3个原则，第一是以快速的搭建为目标，第二是用户只要install下来就能用，三是运行要简单，不需要某个的时候把它干掉就好。
五、优化无极限
最后，每个业务都有不同的业务要求，作为技术人员，要思考的点是优化有没有极限？没有！但是业务是有极限的，业务的目标是什么？业务负责人要充分的考虑这些点。
团队研发也是一样的，你的目标是要解决什么问题？最终要让团队达到什么样的目标或lever，都是需要考虑的。最终在业务里面使用的时候，要细分到每个场景，关注每个细节，根据这些细分的场景和方案，做业务的支持。
© 著作权归作者所有
分类：OSC源创会
字数：5356
