奇异果投屏的进化之路

笔者按:奇异果投屏伴随奇异果TV一路发展至2022年,日活用户已达300多万,用户和我们都对投屏的功能和性能提出了更多的诉求和更高要求,因此2022开始系统地对投屏功能和性能做了扩展和优化。本文立足于TV端,为大家介绍爱奇艺站内投屏优化过程中面临的困难和解决方案,虚心以待您的指正和建议。

01

   优化历程回顾

自2022年初接手投屏功能,先后开展了功能扩展、报障处理提效等工作,至2022年底仍深感投屏功能迭代和问题处理效率不高。投屏功能作为连接手机和电视的桥梁,对其可靠性、稳定性有着很高的要求,夯实基础才能行稳致远,因此开启了投屏优化的历程,针对投屏服务不稳定、线上数据不可用、线上报障解决效率低这三大问题寻求彻底的解决方案。

问题一:投屏服务不稳定

投屏服务为了最大化的保证可用性,需要独立于客户端进程存活,因此采用子进程启动;为了更灵活的迭代以及修复线上问题,需要可以独立部署升级,因此采用独立插件的方式。历史版本的投屏服务架构虽然能够支撑以上两点,但是采用的单服务方案(投屏服务通过ModuleManager注册到客户端),无法很好地支持投屏的双向通信稳定性、投屏服务监测与保活。

新方案采用双服务设计,基于Android系统的Binder机制,可以稳定可靠的感知对端状态并监测连接状态。同时使用Bind和Start两种方式启动Service,提升投屏进程优先级以达到更好的保活效果,进而提供更稳定的双向通信能力。


问题二:线上数据不可用

旧的投屏服务架构,数据打点无法覆盖全流程,导致上报数据不完整,无法监控投屏服务线上质量,更无法分析、解决线上问题。

新的投屏服务架构,设计了3个层级投递监控:

  • 投屏服务模块运行及可靠性监控
  • 投屏协议启动及结果
  • 推片链路步骤打点

每个层级建立相应的业务会话Session机制,每次业务过程生成唯一的SessionId作为会话标识,串联整个业务逻辑生命周期,在各关键节点上报对应业务数据,作为线上数据分析的基础。

  1. 投屏服务模块

此层级的设计目标,确保并提高投屏整体可靠性,服务功能及进程保活,重试重连等数据收集。

该模块完成了线上设备进程保活状态信息的收集,暴露并验证了旧架构不稳定的原因,在新版本上针对性进行规避。如:

数据反馈暴露出的问题

规避和改进方案

startService方式启动子进程,进程优先级较低,进程易被回收并产生频繁重启

加入Bind方式,提升进程优先级

低性能设备进程启动时间长,高版本Android会触发ANR异常(未及时调用Service.startForeground)

Bind方式启动Service,成功后再追加startService

插件机制实现缺陷,丢失bindService的flag参数的进程优先级控制,导致子进程被回收

插件模式下,放弃子进程方式,将投屏服务运行在主进程

部分Rom的LMK机制较严厉,内存紧张时,为保活优先级较高的子进程,可能kill前台可见的主进程

对有问题的设备,放弃子进程方式,投屏服务转为主进程方式

  1. 投屏协议启动

投屏服务的核心功能点在协议层与网络层,此层级设计目标,启动投屏协议模块并跟踪结果,监听系统网络的变更,适时重启投屏协议模块以确保新网络下投屏业务可用。

该模块经过验证和完善后,完成了投屏协议启动的监控及失败原因的统计,并收集汇总线上各设备的网卡及连接信息、协议启动失败在各入口场景下的分布,为分析及提高协议启动成功率提供了源数据及优化回馈。线上分析及存在的问题解决如下:

数据反馈暴露出的问题

规避和改进方案

网络变更场景,协议启动成功率低

正常情况,网络变更时设备网络本就处于不稳定状态,暂无法避免

进程后台存活,设备休眠与激活,导致网络关闭与开启,会频繁触发网络变更重启协议模块,刚激活时网络未准备好

延时处理网络变更事件,可规避部分异常场景,但这个延时无法精准,不能完全避开网络未准备好的时间段,且无法处理激活时间较短又休眠的场景

依据启动时网卡及IP的存在状况,尝试排除无IPv4的启动失败

某些设备双网卡同时连接,WIFI频繁触发断开重连,投屏协议模块频繁重启失败率走高

优化网卡选择策略,优先选择系统活跃网络类型的网卡,避免因交替选择不同网卡频繁重启协议模块

某些设备获取系统活跃网络失败或无,实际上网络可用,收到一些无网络错误码的投递

优化网卡选择策略,系统活跃网络仅作为参照,网卡及IP状况可用时,继续启动协议模块

  1. 推片链路环节

此链路包括TV端收到推片请求,数据与本地能力核验,预缓存起播数据,拉起界面进行播放,记录各阶段及首帧渲染耗时等。

通过该层级统计数据,可分析Qimo投屏和DLNA投屏在各环节点失败折损,阶段耗时占用,起播成功率及起播耗时等。推片环节优化点如下:

数据反馈暴露出的问题

规避和改进方案

跨进程拉起中的链路折损

跨进程拉起进行设备适配,切换到主进程方式,避免拉起新进程

Activity启动阶段的链路折损

后台Activity启动折损,系统限制无法避免,通过引导用户提前打开奇异果应用规避后台拉起的场景

首帧渲染处的链路折损

首帧渲染率与播放成功率有关,与推片的资源相关,无法在推片链路层面解决

Qimo投屏起播耗时优化

针对Qimo投屏场景,优化删减链路环节中的接口调用,与爱奇艺App协调,增加必要的信息字段,避免推片时再请求接口

  1. 投屏指标体系

建立投屏质量体系看板,关注新版本上线后各重要指标的趋势变化,及与旧版本之间的同期对比。其中包括投屏服务的启动成功率、投屏协议启动成功率、Qimo推片起播平均耗时等

  1. 问题发现与分析示例

5.1 投屏协议SDK启动失败及优化过程

1) 问题发现

每次发版初期,投屏SDK成功率会习惯性的跌入90%以下,如下图

2) 分析原因

事出反常必有因,分析问题时间段内投屏SDK启动的投递数据,以设备维度归集后排行,发现SDK启动失败问题有如下特征:

  • 设备型号相对集中,MagicBox_M20C/A两款贡献80%错误量
  • 设备ID相对集中,频繁触发,2款型号触发问题的设备ID仅占其DAU的3-4%

复现遇到难点:

  • 测试设备库无两款设备
  • 都是较老型号,已无法采购设备

只能深入分析个例设备的投屏服务启动及协议启动投递数据序列,以期寻找到共性,抽查几个比较严重的设备id,发现:

  • 失败发生时,系统活跃网络是有线,同时连着wifi,wifi频繁发送变更通知
  • 协议启动时交替选择eth0和wlan0,网卡有变更导致频繁重启SDK,产生巨量启动失败数,间隔最短能到6s每次
  • 异常的设备数量不多,但产生的异常数据量很大

由此推断问题发生场景:

  • 有线网卡和无线网卡都连接的情况下,天猫魔盒M20A/C该2款设备ROM会频繁(间隔<5s)通知WIFI网络断开或重连
  • 奇异果旧选网卡策略是优先选取wifi网卡,此场景会交替使用有线网卡和无线网卡,重新启动投屏SDK
  • 此时处于网络变更期间,网卡状态不稳定,频繁的启动加大了投屏SDK启动失败的概率
3) 优化方案及数据验证

升级调整选网卡策略,增加新的选网卡策略,并支持云配切换新旧策略功能,方便不同策略的数据对比:

  • 优先选取系统活跃网卡
  • 有线网络优先于WIFI

支持新选网卡策略的版本上线后,云配控制M20A/C设备的新版本选网卡策略,如下图橙线(v13.6)走势,投屏SDK成功率明显拐点上行,云配生效后(红色圈)止住下跌趋势,证明新策略有效,之后版本曲线不再出现严重(<90%)的下探

5.2 投屏SDK启动无网络错误码占比偏高

1) 问题发现与分析

版本全量后,投屏SDK成功率仍在98%左右徘徊,离目标99%仍有距离;为此,需要聚焦错误原因,解决错误数据大头,快速提升投屏SDK成功率。

搜集投屏SDK启动数据,以设备维度聚合,按各类错误总数逆序排行表,发现:

  • Top10中,索尼占据了9席,比较典型
  • 从错误类型看,无网络错误占比较大,相应原因是获取系统当前活跃网络出错或无网络
2) 优化方案及数据验证
  • 更改有无网络的判断依赖,系统活跃网络仅作为参照项,检测失败不阻碍后续启动
  • 判断网卡IP作为兜底,如果网卡存在合适IP,可忽略系统活跃网络

新版本上线后,针对该批设备云配网络判断策略,40款设备收集线上修改前后数据进行对比验证如下:

  • 10款型号(涉及sony和小米),错误数/率下降 90%+,效果显著
  • 9款型号,错误数/率下降 50%+,效果明显
  • 10款型号,错误数/率下降仅20%+,效果一般
  • 4款型号,效果低于/接近10%,效果不明显
  • 6款三星设备,未升级覆盖,几乎无效

应用新策略后,全量后整体无网络错误率下降一半左右。如下图,红框所示的版本全量区域,13.7/13.8对比13.6同期优化幅度近50%,红圈区域为应用新策略时间段13.6的错误率下降趋势.

此次适配优化后,版本全量后,投屏协议启动成功率可达98.5%+

问题三:投屏线上报障解决效率低

  1. 困难与对策

困难描述

影响范围

解决方案

TV端日志不全

缺少关键日志,无法定位问题

新投屏服务架构完善了投屏进程的日志上报功能,基于新的日志体系,能够补充更多关键日志

只有单端日志

无法支持双端联合分析

增加移动端投屏报障联动功能,即移动端投屏报障会给TV发指令追加一份TV日志到同一工单;找不到TV设备的问题,协同客服同学引导用户双端报障

只能收集到应用内的日志,无系统日志

无法分析系统行为

暂时无法解决,只能尽量增加应用调用系统接口的日志

只能个案分析

个案问题基本上没有共同特征,无法归纳分析并解决;而且无法判定影响程度

结合线上数据协同分析,尝试解决一类问题,而不是一个问题

扩展发现设备的途径,增加局域网扫码投屏功能,优化网络抖动等网络不稳定原因导致的无法找到TV设备

扩展通信通道,增加远程投屏,建立广域网通信通道

  1. 批量分析方法

关联质量投递数据,建立用户报障批量分析流程,提升用户反馈分析效率,流程如下图

02

   未来可期

总结过去是为了更好的创造未来。经过多团队共同努力,至2023年底,投屏功能在稳定性(99%+)、成功率(98.5%+)、可监控等方面取得了阶段性的成果,为投屏功能的进一步发展、创新打下了坚实的基础。

投屏的未来何去何从?电视作为家庭娱乐中心的地位短时间还不会被轻易撼动,手机作为个人不可或缺的贴身设备,短时间也很难找到替代品,投屏作为连接手机和电视的桥梁,未来目标是实现1+1>2的效果:

  1. 各取所长:
    1. 电视的观影体验更好(大屏、高画质、好音效),但是操控不够便捷;
    2. 手机的操控便捷,但是观影体验不如电视;
  2. 开疆拓土:打破边界、拉近距离,会产生更能多可能性。
    1. 远程投屏:将手机与电视的互动从局域网扩展到广域网,延伸了投屏的边界,同时拉近了人与人的距离,让你的手机可以连接父母的电视;
    2. 万物互联:物联网作为当下科技创新大潮中的一员,已经崭露头角。电视作为家庭的中心,手机作为个人的的延伸,已经通过投屏建立了连接,随着更多家用设备接入物联网,一定能借由投屏这座桥产生更多可能性。

未来已来,愿与大家共同努力创造爱奇艺投屏新生态。



本文分享自微信公众号 - 爱奇艺技术产品团队(iQIYI-TP)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部