全局创建context？
创建一个全局的context，然后退出SDK层房间时不销毁只是停止context。
SDK层进房模型？
业务层房间model（波劵数、主播头像路径、主播userId、主播昵称、在线人数、播放URL、发布URl、会话ID、房间ID、观众头像数组）,SDK层房间model（用户Model(九合ID、主播头像路径、主播昵称、主播身份标识、主播的展示区域)、房间ID、会话ID）。
主播根据SDK层房间Model取出用户Model、然后判断用户身份为主播并全局保存、设置主播特定按钮、开启AVSDK、配置房间参数模型(roomID和房间权限)进入SDK层房间、开启摄像头、开启QAVVideoCtrl视频帧委托、视频正式渲染之前先预览Or倒计时、观众显示毛玻璃。
SDK层进房逻辑？
主播：判断IM已经登录（否则提示Token失效并返回首页）、检查麦克风权限、检查摄像头权限、检查网络、检查模拟器、运行context、创建SDK进房模型进入SDK层房间、设置远程本地视频帧委托、开启麦克风、开启摄像头、（依赖摄像头打开）主播业务层进房逻辑
观众：判断IM已经登录（否则提示Token失效并返回首页）、检查网络、检查模拟器、运行context、设置远程本地视频帧委托、创建SDK进房模型进入SDK层房间、设置远程本地视频帧委托、开启扬声器、请求远程主播画面、观众业务层进房逻辑
业务层进房逻辑？
主播：视频渲染、主播添加倒计时、显示主播头像和主播昵称和观众头像、注册音频和APP应用状态的通知、添加电话监听、添加网络监听、设置BottonBackView可见、开启旁路直播、请求服务器创建业务层房间（开启数据定时器、开启心跳定时器、连接LeanClound）、
观众：视频渲染、观众端添加毛玻璃、显示主播头像和主播昵称和观众头像、注册音频和APP应用状态的通知、添加电话监听、添加网络监听、设置viewerBottomBackView可见、请求服务器进入业务层房间（开启数据定时器、连接LeanClound）
业务层退房逻辑？
主播：断开LeanClound、销毁数据定时器、清空礼物队列、关闭旁路直播（依赖SDK层房间活着）、销毁心跳定时器、判断SDK层房间生命状态决定是否进入SDK层退房逻辑。
观众：断开LeanClound、销毁数据定时器、清空礼物队列、复位礼物界面、判断SDK层房间生命状态决定是否进入SDK层退房逻辑。
判断SDK层房间生命状态决定是否进入SDK层退房逻辑？
判断SDK层房间活着：执行SDK层的退房逻辑、控制器跳转逻辑
判断SDK层房间死亡：控制器跳转逻辑
SDK层退房逻辑？
主播：判断摄像头打开：关闭摄像头、关闭麦克风扬声器美颜后退出SDK层房间（停止运行context）。判断摄像头关闭：停止运行context。
观众：判断SDK层房间生命状态。判断SDK层房间死亡：停止context。判断SDK层房间活着：取消远程视频的继续请求、关闭麦克风扬声器后退出SDK房间、停止context。
控制器跳转逻辑？
移除键盘通知应用程序前后台通知移除音频中断通知、移除IM状态监听、移除电话状态监听、移除网络状态监听、设置音频为初始状态、销毁渲染层
主播：主播请求服务器关闭业务层房间（主播Push到直播结束控制器）
观众：观众请求服务器退出业务层房间（观众POP到首页）（如果被动退出请求服务器历史业务层房间信息（观众Push到直播结束控制器））
"直播间关闭"消息处理逻辑？
来源一：主播请求服务器关闭业务层房间。来源二：服务器超过30秒没有监听到心跳关闭业务层房间。对于主播来说，不想接收来源一的消息，很简单，把断开LeanCloud放在主播请求服务器关闭业务层直播间以前，这样就什么都搞定了。
主播：因为是先断开LeanClound后请求服务器，所以主播只会接收到来源二的消息。我想要的是，一旦是来源二的消息，就算主播和观众同时进入业务层退房逻辑，都是会先断开LeanClound，这样就算主播请求服务器关闭业务层房间发送了一个“直播间关闭消息”，观众端也已经断开了LeanClound，根本就搜索不到好吧！所以，直接就进入业务层退房逻辑吧，无论是只有观众接收到“直播间关闭”的消息，还是主播和观众同时接收到“直播间关闭”的消息，根本都是一点问题都没有好吧！因为我总是在业务层退房逻辑里面把断开LeanClound放在首位。
观众：来源一和来源二都需要处理，直接进入业务层退房逻辑。
SDK层房间异常关闭逻辑？
判断身份是主播：业务层退房逻辑。
判断身份是观众：不需要对SDK层逻辑做操作，业务层的逻辑又会在接收到LeanClound类型6的消息后开始执行。
现在有一个巨大的问题就是SDK层房间被异常关闭后，主播和观众都会进入业务层退房逻辑，可是按照正常逻辑，关闭业务层房间、关闭SDK层房间，然后有进入业务层退房逻辑，这不是重复了么。得判断是正常SDK房间退出还是被剔除SDK层房间，两者最大的区别，就是正常退出SDK层房间会调用exitRoom这个方法。只要调用了exitRoom这个方法，自然就不是被剔除房间了。就不需要再退房的通知进入业务层退房逻辑了。默认就是被剔除SDK层房间，除非在调用exitRoom方法的时候将被剔出SDK层房间的属性置为NO,自然就不会进入业务层的退房逻辑了。当然这个判断必须写在停止销毁Context之后。当然每次启动Context的时候都是默认被剔除SDK层房间的属性为YES，本来想写在创建Context的代码里，但是觉得不妥，不一定每次进入SDK层房间都会创建Context，但是有一点可以肯定，无论上一次到底是正常退出SDK层房间还是被剔出SDK层房间，都会重新运行Context。
多次点击发起直播多次Push直播控制器？
解决方案就是点击发起直播按钮，然后直播按钮位不可点击状态，按理说不科学，不是那个HUD就已经可以实现这个功能了么，如果主播正在向秀波服务器请求SDK层房间的ID号，这个时候是一直有一个HUD圈圈在发起直播的控制器上旋转，这个时候发起直播控制器的所有按钮应该是不可点击状态才对呀，为什么可以连续多次点击发起直播的按钮呢，这严重不科学，按理说根本就不应该出现这样的问题才对。
还有退出直播间不显示？
观众业务层退房都会请求服务器退出业务层房间，只要观众主动退出就会请求服务器退出业务层房间，只要退出成功，业务层的其它成员就会接收到谁谁谁退出业务层房间，类型为8的消息。这个消息不用显示出来，仅仅是为了更新观众头像列表来用，只是我一直想测试一下如果我不开启心跳，然后服务器发来“直播间关闭”的消息，到底哪个主播会不会进入SDK层退房逻辑，这个问题很关键呢，直接决定了如果业务层房间被秀波服务器异常关闭，主播能否接收到“直播间关闭”的消息，并作出进一步的处理。现在就用陈于的手机测试一下，到底业务层房间被异常关闭，主播进步进入业务层退房逻辑。还有现在居然有另外一个问题也附带解决了，就是我不用担心业务层房间还存在，但是SDK层房间已被关闭的问题了，毕竟，现在只要我推到后台，永远都是30秒就把业务层关闭了，然后观众就退出了，当然那个主播则会在回到前台后第一时间处理“直播间关闭”的消息，简直不要太溜呀。所以说什么吗等90秒关闭SDK层房间真是看不见了。现在我需要屏蔽不显示谁退出的消息了。经常出现这么一个情况，就是观众快进快出，这样会带来的问题表现是，观众头像列表重复出现，换句话说，上一次退出的时候，没有及时退出业务层的房间，然后进入的时候又请求了进入业务层房间，这样的问题如此导致头像重复出现，很明显就是观众退出业务层房间不够及时，活着退出业务层房间没有及时发送LeanClound消息来刷新头像。如此一来，重复加载头像的问题就是没有及时请求退出业务层房间的原因。
主播倒计时？
观众：添加渲染层、请求远程视频、添加了毛玻璃、第一帧视频画面出现、移除毛玻璃、开始视频渲染
区分主播关闭摄像头到底是临时中断直播还是正常结束直播？
当观众收到有人关闭摄像头的通知时，观众在这个通知里执行的任务包括重新请求远程视频、创建“主播暂停直播”的本地消息显示到聊天框。那么问题来了，当主播正常结束直播时也会先关闭摄像头，观众也会创建“主播暂停直播”的本地消息，这不是我想看到的结果，说白了就是我想区分主播到底是临时中断直播还是正常结束直播。
视频图片帧渲染逻辑？
用户退出SDK层房间之后务必需要注意一点，就是一定要停止渲染、渲染层父视图移除、将渲染层置空。这个问题很重要，一旦渲染层没有被正常移除和置空，直接造成控制器的内存释放不了，意味着下一次进入房间控制器时，新的渲染层直接添加到了旧的渲染层上，重复添加渲染层，问题很严重。
房间成员头像和波劵数量刷新的问题？
数据刷新的问题，自从我融入观众请求服务器进入房间和请求服务器退出房间都发送LeanClound的消息之后，现在的我就是1分钟再刷新一次头像列表，然后不用刷新房间人数，直接就以头像的个数为准。而且主播的波劵数量也是1分钟更新一次，相当于就是1分钟校正一下数据，包括校正观众头像和主播波劵。在没有请求数据的时候，观众头像列表和主播波劵全靠服务器发来的消息来刷新，来了和退出都会刷新头像，礼物消息就刷新波劵数量。
心跳？
主播还有一个心跳定时器不仅要关闭，还要直接销毁它。那么这里有一个疑问，就是我如果退出房间依然请求服务器心跳，会造成什么问题，因为单例嘛，从APP启动到APP关闭都是只初始化一次，那么势必我如果不在正确的时间里停止心跳监听，APP会一直请求服务器心跳，那么这里面有一个问题，就是到底什么事时间才是结束心跳监听的最佳时间呢，说实话，当我关闭SDK房间的那一刻，就真的没有什么必要再去请求服务器监听心跳了。所以最好的时间就是关闭摄像头的时候，一谈到摄像头的开关和关闭，必须要考虑一个前提，就是主播关闭摄像头不一定就是要退出房间，很有可能是退到后台或闹钟电话中断。除了在SDK摄像头关闭的回调事件里知道了主播关闭摄像头以外，其它是啥也不知道呀，如果要区分这个摄像头关闭的事件到底是因为主播结束直播还是中断直播，还需要一个附加条件，可是这个附加条件是什么呢？到底是什么附加条件呢？莫非是主播请求服务器结束直播发送过来的LeanClound消息。除了这个消息，还能更加准确地判断关闭摄像头的具体意义么？
数据请求单例类？
置空数据请求单例类的委托，这样就算数据请求单例类请求到了数据，单例类对象想要通过委托属性调用协议里的方法传递网络请求到的数据也是徒劳的，当然这不是因为什么控制器没有实现这个协议方法的原因，而是因为数据单例类的委托属性都是空的呀，有木有！但是假如我们在销毁控制器的时候，不置空数据单例类的委托属性，那么好像也没什么问题，因为本质上，当初是把控制器本身self赋值给数据单例类对象的委托属性上，现在控制器self都已经销毁了，就相当于将数据单例类对象的委托属性销毁了，还有还什么必要在控制器里置空数据单例类对象的委托属性呢？当然，可能置空数据单例类对象的委托属性的唯一价值在于可以在控制器销毁之前结束数据请求单例类的数据回调。
LeanClound单例帮助类？
对于LeanClound通信来说，同一个用户本来在A聊天室，如果在没有退出A聊天室的情况下又进入B聊天室，必然会出现大问题。所以问题的关键是究竟在哪个地方来退出Leanclound通信。那需要分析我到底在什么时候不再需要LeanClound了，肯定的，对于主播来说，只要请求服务器退出直播间成功之后即可退出LeanClound。对于观众来说，自然就是在接收到服务器发来主播退出直播间消息6之后，直接就退出LeanClound了。
为什么必须在销毁控制器时移除通知？
音视频直播控制器需要移除的通知包括键盘通知、应用程序前后台通知、音频中断的通知。通知本质上就是传递一个委托对象到通知中心去，这个被传递的委托对象通常就是控制器self本身。一旦控制器销毁，相当于在其它地方触发事件后想要通过这个通过通知传递过去的控制器self来调用控制器对象.m文件里面写的方法，这样必然造成崩溃呀，因为不仅调用的方法没有被实现，更是这个控制器self都是空的状态。这怎么能行，通知一定得注意删除呀。控制器的通知必须得成双成对的出现。
直播异常情况的处理？
网络改变和网络重连监听、IM登录状态、电话监听、音频中断、APP应用前后台
音视频房间逻辑的优化？
1、 AVChatRoom特点: 后台会控制每秒收到的消息数在一定数量(比如5条/s)，这样界面就不会频繁有消息刷新
2、是否支持消息缓存，而不是立即显示，主要是看大消息量时，立即显示会导致界面卡顿， 因不清楚各App的消息种类，以及消息类型（是否支持IM等），故放到业务层去处理，各App可依照此处逻辑为0时，立即显示 为1时，会按固定频率刷新
3、AVSDK在直播场景下使用，不要频繁切换context，可以在用户注销，或被踢下线的时候才stopContext
4、调试的时候手机距离较近容易产生啸叫(物理现象：录音机与扬声器较近时)
APP旁路直播？
HLS推流（AV_ENCODE_HLS），判断房间环境是否允许推流-----判断是否允许重试-------正式开始推流———根据推流的各种参数构建推流请求模型-----通过[IMSdkInt sharedInstance]调用推流的请求———通过推流请求模型接收返回的对象
AVSDK的重试逻辑？
重复操作的逻辑———设定最大尝试次数——常量整型变量保存当前的尝试次数——判断操作失败—>累加变量——>对比当前尝试次数和最大尝试次数—>分线程延时1秒重新请求——>递归重新执行此方法
直播的异常处理？
用户从正在听QQ音乐和看视频直播过程中进入直播间，或者说正在直播时出现了闹钟，
APP电话监听？
用户正在直播间，有人打来QQ电话，电话完毕需要重新进入直播APP，
Delloc方法不调用造成内存泄露？
delegate、Block、定时器
LeanClond私聊？
主播：建立与观众A的会话，通过会话发送私聊
视频录制？
录制功能—————IMSDK单例对象——————调用开始视频录制的方法——————传入两个数据模型作为参数—————房间模型（房间的ID号和聊天室的ID号）———————录制视频需要做的一些模型(录制视频生成的视频名称、视频的索引标签、视频分类的ID、SDK、是否转码、是否截图、是否打水印)
APP定时器？
定时器写在数据请求工具类，开启直播间成功后开启，控制器销毁时关闭，无论正常退出还是意外退出，工具类如何获取控制器关闭的事件，delloc方法中告诉工具类，请工具类关闭定时器
APP处理远程通知？
接收到远程通知，判断用户是否登录，已经登录则判断APP应用的当前状态，推送的字典aps键里面alertBody[aps object:@“alert”]，mesType决定推送消息点击后的不同执行状态，mainPage直接就是一个进入房间的字典。如果应用处于前台正运行状态，则将远程消息的内容转化成本地通知，唯一不科学的就是为什么这本地通知只是出现在通知栏，并不会向饿了么的那个红包一样先弹出来一下，这严重不科学呀！应用处于后台和待激活状态，则判断推送的消息类型，1和2的类型进入用户的个人中心，3和4的类型进入直播间。
微信公众号提现？
发起微信提现，判断微信的SnsOpenID和SnsUserID是否为空。如果为空，则调用微信登录，在微信登录成功的Block回调里面存储微信的两个ID到本地，接着调用提现的接口。如果登录失败，在Block回调里面提现登录微信异常的错误到提现页面，同时返回到上一个页面。如果判断到本地已经存在了微信的两个ID号，那么直接发起提现请求，在请求成功后直接Block从单例帮助类回调到提现页面。发送提现请求失败有两种情况：一种就是是未关注公众号，另一种就是其他错误(典型ID失效)。尤其注意微信的两个ID通常都是有时效性的，除了退出登录的时候清空微信的两个ID，还有一种更重要的方法就是要注意一个时间，就实现一个要求，在超出一个时间段之后自动清空这两个ID。当然现在是通过提现的网络请求传入微信的连个ID才可以判断是否失效的。当然，这里一般也不会失效，因为必须是微信登录后，两个ID才有值的。
APP不使用云通信IM而是用LeanClound？
删除IMCore且初始化IM通信设置为不开启聊天，更改IM头文件为只是简单实用登录不使用聊天功能的那个头文件，同时关闭IM云通信的错误日志打印，导入LeanCloundSDK 并在APPDelegate初始化开启SDK，创建一个可用聊天室ID放进房间模型。用户通过ID使用聊天功能用户ID初始化laenClound 获得leanClound对象，然后设置这个Client对象的委托，连接聊天服务器，根据聊天室房间号找到当前的群聊会话，根据返回的会话ID加入当前会话，接收新消息，消息转模型，特殊消息特殊处理，刷新内容展示，键盘监听，构建消息，设置消息类型（方便解析时不同颜色），发送消息。
APP登录？
微信：微信登录后Block返回的两个ID请求登录的接口
手机：手机号和密码请求登录的接口
登录的网络请求成功后返回九合ID和用户ID和TLS签名，本地保存TLS签名、九合ID、用户ID等其他一些列个人信息，然后dismiss登录注册页面，发送通知进入个人中心的页面，自然在进入个人中心的页面就会调用viewWillAppear的方法，这个方法里面请求服务器刷新个人资料，这里特别坑的一点就是，个人中心的资料居然是来源于两个接口，一个界面的数据来源于来个网络请求，我一下子就想到了那个RAC的双信号处理任务依赖呀，当然，用那个操作队列来实现也是一个特别硬气的方法。当然在登录成功获取到TLS票据之后，最最重要的一点就是登录IM了。
APP登录IM?
登录秀波服务器后会返回一个TLS票据，登录IM，登录失败，然后本地更具九合ID去请求一个新的TLS票据，自然就可以重新登录了。1、用户的账号类型accountType 2、用户名identifier 3、鉴权TokenuserSig 4、 App用户使用OAuth授权体系分配的AppidappidAt3rd 5、用户标识接入SDK的应用IDsdkAppId
APP支付？
支付宝：反馈支付结果到APP，APP请求APP服务器的支付状态，返回支付失败，再试一次，回馈结果，返回支付成功，就不在执行第二次，查询APP服务器支付状态，构建一个支付宝支付模型，模型的所有属性的内容拼接成字符串，在给这个字符串拼接上特定格式签名字符串，通过AlipaySDK实例化一个单例调用方法开始支付，支付结果通过字典反馈，判断字典的支付状态的值，判断支付宝返回的支付结果为真
点击发起直播？
点击开始直播，默认分享微信,分享成功之后返回到应用的Block回调里面,跳转控制器
更新头像列表？
方案一：观众进入直播间，请求服务器就会获取到当前房间的观众，然后定时器每15秒刷新一次数据
方案二:观众进入直播间时，请求服务器进入直播间，服务器群发leanClound消息,自带头像路径和用户ID,更新数据到头像列表，然后请求数据变成1分钟一次作为数据矫正。
函数式编程链式调用？
好想用一下函数式编程的思想，首先有一个工具类，一个采用链式编程思想的工具类，然后就是可以通过Block参数的输入值将这个工具类的对象传递成被操作的对象，这样就可以把很多操作写在一个代码块里，这多幸福。现在就解决退出直播间这个问题，都需要执行哪些操作，然后通过BlockOperation添加一些列操作，这样不经逻辑清楚，避免逻辑混乱，更可以为后面的RAC做准备呢！首先就是考虑观众退出吧，这个问题好忧伤，弄了这么多次，就没有成功过，到现在还没有信心，难道不是很忧伤么，现在 看到有了操作队列简直就像遇到救命稻草一般，可以完美的承载我的操作野心，让我把所有的任务都封装成一个操作队列之中，这样简直就是完美了，好了，废话不多说，直接打断点分析逻辑和思路。找出观众退出房间所有应该执行的任务，然后将这些任务通通包装成操作对象然后添加到队列之中
APP前后台切换？
前台：打开相机，开启渲染，立马向服务器发一个心跳抢救回来，重新开启定时器开启心跳
后台：关闭相机，停止渲染，停止定时器，废弃心跳定时器并置空。iOS进入后台或锁屏造成的不活跃状态，立马终止了context，主播重新打开，摄像头和一切麦克风都无法重新恢复，由于context已被销毁，也无法通过context正常关闭功能和退出房间，对于主播必须先关闭摄像头，可是现在已经关闭了摄像头，唯一解决方法是主播进入后台时不销毁context，在即将进入后台的时候继续摄像头的录制和音频连接，说白了前台后台一个样，直到主播主动关闭摄像头退出房间才销毁context。现在问题进入后台是自动就关闭了context。解决方法更换新的SDK，更新SDK到1.8.1之后推到后台并未立刻终止context，只是暂停了context，但是一旦推到后台就会结束服务器心跳的请求，服务器再30秒没有接收到心跳将会强制关闭房间，使房间的所有成员变成无家可归的人。而且程序退到后台会应为渲染的问题造成程序崩溃，我想知道的是推倒后台之后，摄像头是否会依然会回调本地视频帧，这个问题很重要，假如在程序推到后台后依然回调视频帧说明程序退到后台依然正常工作，如果程序在后台依然运行就会像打电话退到后台那样在全屏幕上方显示一个红色通知，因此对于渲染层来说，必须在程序进入后台的时候停止渲染，否则出现视频回调但是渲染层停止工作的问题，假如程序进入后台后摄像头立马停止工作，应该只是中断心跳的感觉，现在退到后台AVSDK暂停。程序进入后台后，摄像头停止视频回调，如果后台的逗留时间超过80秒，这时候再重新回到前台的时候，这个房间的所有成员都成为无家可归的人了，主播如果这时候去执行关闭摄像头的方法直接就是赤裸裸地找死啊，毕竟房间都已经死了呀。主播现在也不需要去退房了，直接告诉服务器退出房间吧，我觉得这个时候也不再需要去请求退出房间的接口吧，毕竟服务器再关闭异常的主播房间之后会群发一个直播间关闭的消息。然后销毁context，只有这样控制器才能delloc方法回收内存，渲染层的delloc回收内存，如果小于30秒则不会出现这样的问题。
APP权限判断？
第一次使用APP时系统会弹出Alert框让用户选择是否允许授权，包括摄像头和麦克风。以后用户在进入直播间的时候每次都要先判断权限，如果第一次拒绝了授权需要Alert提示用户去隐私里面进行设置，同时pop销毁控制器，只有摄像头和麦克风都已经授权，才继续下面的操作。
APP判断IM登录状态？
判断IM是否是登录状态
APP添加电话监听？
继承的意义？
继承重写父类的初始化方法，调用新增的方法或为新增的属性赋值。重写父类的方法，网络改变和网络重连监听、IM登录状态、电话监听、音频中断、APP应用前后台
APP测试?
测试部设备有限，特邀大家一起来测试，各位亲，不要钱，免费的哟，玩得不开心还可以提个现，一万两万保证后台不找你，测试评论时少些情绪，多些细节哈，做一个Nice的人！前方高能，测试重点突出：1、电话中断 2、网络切换 3、音频中断 4、前后台切换 5、动画与内存 6、旁路直播 7、流畅Vs清晰 8、提现+充值 9、三方分享造成的直播中断 10、定时器的数据刷新 11、内存释放 12、三方登录 13、直播间生命周期 14、侧弹动画的队列排序 15、聊天界面的消息冲突
不使用IM改用leanClound的细节？
用户ID初始化laenClound 获得leanClound对象——设置对象委托-----连接聊天服务器——根据聊天室号找到当前群聊会话-----加入当前会话----- 接收新消息——消息转模型-----特殊消息特殊处理------刷新内容展示———键盘监听——构建消息-----设置消息类型（方便解析时不同颜色）------发送消息
删除IMCore-----关闭IM通信-------更改IM头文件———报错代码全部关闭———引进LeanCloundSDK ———APPDelegate初始化———创建一个可用聊天室ID放进房间模型——— 用户通过ID使用聊天功能
研发工程师，视频娱乐，技术选型，体验优化，问题解决，单源上传，小于三秒，美颜滤镜，采集，录制，滤镜，编码，打包，传输，拆包，渲染，播放，CDN，带宽，加速优化，延迟，开屏时间，卡顿率，秒开，画面跳跃，声音不连贯，延迟因素，GOP，组组图片流，IPB帧，大小小，I帧之后的缓存，请求服务器先拿有I帧的缓存，通信协议，RTSP，TCPUDP混合复杂，部分CDN不支持，RTMP，仅TCP三次握手，简单，CDN全支持，HLS，Http协议，跨平台，HTTP—FLV，低延迟，需要播放器。buffer，避免频繁抖动和卡顿。CDN全国各地分布基点。如何秒开，开屏等待时间，DNS解析，连接服务器，判断服务器是否有缓存，等关键帧解码，建立连接，等待关键帧，播放器渲染，DNS预解析，链路检测，实时更改码率，网络优化，CDN加速，负载均衡，视频转码，多种协议，封面截图，直播录制，分布式存储集群，首屏秒开，低卡顿，低延时，多码率，多格式，多终端，视频传输架构，就近IP，DNS智能解析，IP调度，互联互通，跨网络访问，丢包严重，克服物理距离传输，丢包重发，接流，录制，实时截图，图片鉴黄，机器学习引擎，标清HLS，流畅FLV,视频滤镜，多清晰度，容错处理，视频质量大数据分析，系统瓶颈，CPU消耗，内存消耗，线程并发，机房快速迁移，看数据更高效运营