키위 과일 스크린 프로젝션의 진화

작성자 메모: Kiwi Screen Mirroring은 2022년까지 Kiwi TV와 함께 개발되었으며 일일 활성 사용자가 300만 명 이상에 도달했습니다. 사용자와 우리 모두 화면 미러링의 기능과 성능에 대해 더 많은 요구와 더 높은 요구 사항을 제시했기 때문에 시작될 것입니다. 2022년에는 스크린 프로젝션 기능과 성능이 체계적으로 확장되고 최적화되었습니다. 이 기사는 TV 측면을 기반으로 하며 iQiyi 사이트에서 화면 프로젝션을 최적화하는 과정에서 직면하는 어려움과 해결책을 소개합니다. 우리는 여러분의 수정과 제안을 환영합니다.

최적화 프로세스 검토

2022년 초 화면 프로젝션 기능을 인수한 이후 기능 확장, 문제 해결 효율성 향상 등의 작업을 순차적으로 수행해 왔으며, 2022년 말까지 화면 프로젝션 기능의 반복 및 문제 처리 효율성이 여전히 우수하다고 느꼈습니다. 높지 않습니다. 휴대폰과 TV 사이의 가교 역할을 하는 스크린캐스팅 기능은 신뢰성과 안정성에 대한 요구 사항이 높으며, 탄탄한 기반을 마련해야만 꾸준하고 장기적인 발전을 이룰 수 있습니다. 따라서 우리는 불안정한 것을 목표로 하는 스크린캐스팅 최적화 프로세스를 시작했습니다. 우리는 온라인 문제 해결의 가용성 및 효율성 저하라는 세 가지 주요 문제에 대한 철저한 솔루션을 추구합니다 .

문제 1: 스크린캐스트 서비스 가 불안정합니다.

최대 가용성을 보장하려면 화면 미러링 서비스가 클라이언트 프로세스와 독립적으로 유지되어야 하므로, 온라인 문제를 보다 유연하게 반복하고 수정하려면 독립적으로 배포 및 업그레이드해야 합니다. 그래서 독립된 플러그인을 사용합니다. 스크린 캐스팅 서비스 아키텍처의 기존 버전은 위의 두 가지 사항을 지원할 수 있지만 채택된 단일 서비스 솔루션(스크린 캐스팅 서비스는 ModuleManager를 통해 클라이언트에 등록됨)은 스크린 캐스팅, 스크린 캐스팅의 양방향 통신 안정성을 제대로 지원할 수 없습니다. 서비스 모니터링 및 살아 유지.

새로운 솔루션은 이중 서비스 설계를 채택하고 Android 시스템의 바인더 메커니즘을 기반으로 하며 피어 상태를 안정적이고 안정적으로 감지하고 연결 상태를 모니터링할 수 있습니다. 더 나은 연결 유지 효과를 달성하고 보다 안정적인 양방향 통신 기능을 제공하기 위해 바인딩 및 시작을 사용하여 서비스를 동시에 시작하면 스크린 캐스팅 프로세스의 우선 순위를 높일 수 있습니다.

문제 2: 온라인 데이터를 사용할 수 없습니다.

기존 스크린 프로젝션 서비스 아키텍처에서는 데이터 관리가 전체 프로세스를 포괄할 수 없기 때문에 보고된 데이터가 불완전하고 스크린 프로젝션 서비스의 온라인 품질을 모니터링할 수 없으며 온라인 문제를 분석하고 해결할 수 없습니다.

새로운 스크린 프로젝션 서비스 아키텍처는 세 가지 수준의 전송 모니터링으로 설계되었습니다.

스크린 프로젝션 서비스 모듈 운영 및 신뢰성 모니터링
스크린캐스팅 프로토콜 시작 및 결과
링크를 푸시하는 단계

각 레벨은 해당 비즈니스 세션 세션 메커니즘을 설정합니다. 각 비즈니스 프로세스는 세션 식별자로 고유한 SessionId를 생성합니다. 이는 전체 비즈니스 로직 수명 주기를 연결하고 온라인 데이터 분석의 기초로 각 핵심 노드에서 해당 비즈니스 데이터를 보고합니다.

스크린 프로젝션 서비스 모듈

이 수준의 설계 목표는 스크린캐스팅, 서비스 기능, 프로세스 연결 유지, 재시도 및 재연결, 기타 데이터 수집의 전반적인 신뢰성을 보장하고 향상시키는 것입니다.

이 모듈은 온라인 장치 프로세스 연결 유지 상태 정보 수집을 완료하고, 이전 아키텍처의 불안정성에 대한 이유를 노출 및 확인하고, 새 버전에서 표적 회피를 구현했습니다. 좋다:

데이터 피드백으로 인해 노출되는 문제	회피 및 개선 솔루션
startService 메소드는 하위 프로세스를 시작하며 프로세스 우선순위가 낮고 프로세스가 쉽게 재활용되며 자주 다시 시작됩니다.	프로세스 우선순위를 높이기 위해 Bind 메소드 추가
저성능 기기 프로세스는 시작하는 데 시간이 오래 걸리고 Android 상위 버전에서는 ANR 예외가 발생합니다(Service.startForeground가 제때 호출되지 않음).	바인딩 모드에서 서비스를 시작한 후 성공하면 startService를 추가합니다.
플러그인 메커니즘의 구현에 결함이 있고, BindService 플래그 매개변수의 프로세스 우선순위 제어가 손실되어 하위 프로세스가 재활용됩니다.	플러그인 모드에서는 하위 프로세스 모드를 포기하고 메인 프로세스에서 화면 미러링 서비스를 실행합니다.
일부 Rom의 LMK 메커니즘은 메모리가 부족할 때 더 높은 우선순위의 하위 프로세스를 유지하기 위해 포그라운드에 표시되는 기본 프로세스가 종료될 수 있습니다.	문제가 있는 장치의 경우 하위 프로세스 모드를 포기하고 스크린캐스팅 서비스를 기본 프로세스 모드로 전환하세요.

스크린캐스트 프로토콜이 시작되었습니다.

화면 프로젝션 서비스의 핵심 기능 지점은 프로토콜 계층과 네트워크 계층에 있습니다. 이 수준의 설계 목표는 화면 프로젝션 프로토콜 모듈을 시작하고 결과를 추적하고, 시스템 네트워크의 변경 사항을 모니터링하고, 화면 프로젝션 프로토콜을 다시 시작하는 것입니다. 새로운 네트워크에서 화면 프로젝션 서비스를 사용할 수 있도록 적시에 모듈을 설치합니다.

검증 및 개선 후, 이 모듈은 스크린캐스팅 프로토콜 시작 모니터링 및 실패 원인 통계를 완료했으며, 분석을 위해 각 온라인 장치의 네트워크 카드 및 연결 정보와 각 진입 시나리오의 프로토콜 시작 실패 분포를 수집 및 요약했습니다. 프로토콜 시작 성공률은 소스 데이터 및 최적화 피드백을 제공합니다. 기존 문제에 대한 온라인 분석 및 해결 방법은 다음과 같습니다.

데이터 피드백으로 인해 노출되는 문제	회피 및 개선 솔루션
네트워크 변경 시나리오, 프로토콜 시작 성공률이 낮음	정상적인 상황에서 네트워크가 변경되면 장치 네트워크는 이미 불안정한 상태에 있으므로 당분간 피할 수 없습니다.
프로세스는 백그라운드에서 유지되며 장치는 절전 모드 및 활성화되어 네트워크가 닫혔다가 열리게 됩니다. 네트워크가 처음 활성화되면 네트워크 변경이 자주 발생하고 프로토콜 모듈이 다시 시작됩니다.	네트워크 변경 이벤트 처리를 지연하면 일부 비정상적인 시나리오를 피할 수 있지만 이 지연은 정확할 수 없고 네트워크가 준비되지 않은 기간을 완전히 피할 수 없으며 활성화 시간이 짧고 네트워크가 휴면 상태인 시나리오를 처리할 수 없습니다. 시작 시 네트워크 카드 및 IP의 존재 여부를 기반으로 IPv4 없이 시작 실패를 제거해 보십시오.
일부 장치에는 동시에 연결된 이중 네트워크 카드가 있고 WIFI는 연결 끊김과 재연결을 자주 트리거하며 화면 프로젝션 프로토콜 모듈이 자주 다시 시작되고 실패율이 증가합니다.	네트워크 카드 선택 전략을 최적화하고 시스템에서 활성 네트워크 유형이 있는 네트워크 카드에 우선순위를 부여하여 서로 다른 네트워크 카드를 번갈아 선택하여 프로토콜 모듈이 자주 다시 시작되는 것을 방지합니다.
일부 장치는 시스템의 활성 네트워크를 얻지 못했거나 네트워크가 없었습니다. 실제로 네트워크를 사용할 수 있었고 네트워크 오류 코드 없이 일부 전송을 받았습니다.	네트워크 카드 선택 전략을 최적화하십시오. 시스템의 활성 네트워크는 참조용으로만 사용됩니다. 네트워크 카드 및 IP 상태를 사용할 수 있으면 프로토콜 모듈을 계속 시작하십시오.

푸시 링크 링크

이 링크에는 푸시 요청을 수신하는 TV 측, 데이터 및 로컬 기능 확인, 시작 데이터 사전 캐싱, 재생을 위한 인터페이스 실행, 각 단계 및 첫 번째 프레임 렌더링 시간 기록 등이 포함됩니다.

이러한 수준의 통계 데이터를 통해 Qimo 스크린캐스팅 및 DLNA 스크린캐스팅의 각 링크별 실패 및 피해, 스테이지 시간 소비, 시동 성공률 및 시동 시간 등을 분석할 수 있습니다. 영화 프로모션 프로세스의 최적화 포인트는 다음과 같습니다.

데이터 피드백으로 인해 노출되는 문제	회피 및 개선 솔루션
크로스 프로세스 풀업의 링크 손실	장치 적응을 위해 여러 프로세스를 풀업하고 새 프로세스가 시작되지 않도록 기본 프로세스 모드로 전환합니다.
활동 시작 단계 중 링크 손실	백그라운드 활동 시작이 손상되고 시스템 제한을 피할 수 없습니다. 사용자에게 미리 Kiwi 앱을 열도록 안내하면 백그라운드 시작 시나리오를 피할 수 있습니다.
첫 번째 프레임 렌더링 시 링크 손실	첫 번째 프레임 렌더링 속도는 재생 성공률 및 동영상 푸시 리소스와 관련되며 푸시 링크 수준에서는 해결할 수 없습니다.
Qimo 스크린캐스팅 시간 소모적 최적화	Qimo 스크린캐스트 시나리오의 경우 링크 링크의 인터페이스 호출을 최적화 및 삭제하고, iQiyi 앱과 조정하고, 필요한 정보 필드를 추가하고, 영화를 푸시할 때 인터페이스 요청을 방지하세요.

스크린 프로젝션 표시 시스템

화면 투사 품질 시스템에 대한 게시판을 구축하고, 새 버전이 출시된 후 중요 지표의 추세 변화에 주목하고, 같은 기간 동안 이전 버전과 비교합니다. 여기에는 스크린캐스팅 서비스의 시작 성공률, 스크린캐스팅 프로토콜의 시작 성공률, Qimo 비디오 방송을 시작하는 데 걸리는 평균 시간 등이 포함됩니다.

문제 발견 및 분석 예시

5.1 화면 미러링 프로토콜 SDK 시작 실패 및 최적화 프로세스

1) 문제 발견

각 릴리스가 시작될 때 화면 미러링 SDK의 성공률은 아래와 같이 습관적으로 90% 미만으로 떨어집니다.

2) 원인 분석

문제 기간 동안의 화면 미러링 SDK 시작 전달 데이터를 분석하고 장치 차원을 기준으로 순위를 매긴 결과 SDK 시작 실패 문제에는 다음과 같은 특징이 있음을 확인했습니다.

장치 모델은 상대적으로 집중되어 있으며 MagicBox_M20C/A 두 모델이 오류의 80%를 차지합니다.
두 모델에서 문제를 유발하는 기기 ID는 상대적으로 집중되어 있으며 DAU의 3~4%에 불과합니다.

재생산 시 발생하는 어려움:

테스트 장비 라이브러리에 두 개의 장치가 없습니다.
모두 구형 모델이라 더 이상 장비 구매가 불가능합니다.

우리는 공통점을 찾기 위해 화면 프로젝션 서비스 시작 및 프로토콜 시작 전달 데이터 시퀀스에 대한 심층 분석만 수행하여 몇 가지 심각한 장치 ID를 무작위로 확인한 결과 다음과 같은 사실을 발견했습니다.

오류가 발생하면 시스템의 활성 네트워크가 Wi-Fi에 연결되어 자주 변경 알림을 보냅니다.
프로토콜을 시작할 때 eth0과 wlan0이 교대로 선택됩니다. 네트워크 카드의 변경으로 인해 SDK가 자주 다시 시작되어 매번 시작 실패 횟수가 많아질 수 있습니다.
비정상적인 장치의 수는 많지 않지만 생성되는 비정상적인 데이터의 양은 많습니다.

이를 통해 문제가 발생하는 시나리오를 추론할 수 있습니다.

유선 네트워크 카드와 무선 네트워크 카드가 모두 연결된 경우 두 장치 Tmall Magic Box M20A/C의 ROM은 WIFI 네트워크에 연결 해제 또는 재연결을 자주(간격 <5초) 알립니다.
Kiwi의 기존 네트워크 카드 선택 전략은 Wi-Fi 네트워크 카드에 우선 순위를 부여하는 것입니다. 이 시나리오에서는 유선 네트워크 카드와 무선 네트워크 카드가 교대로 사용되며 화면 미러링 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%+

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

困难与对策

困难描述	影响范围	解决方案
TV端日志不全	缺少关键日志，无法定位问题	新投屏服务架构完善了投屏进程的日志上报功能，基于新的日志体系，能够补充更多关键日志
只有单端日志	无法支持双端联合分析	增加移动端投屏报障联动功能，即移动端投屏报障会给TV发指令追加一份TV日志到同一工单；找不到TV设备的问题，协同客服同学引导用户双端报障
只能收集到应用内的日志，无系统日志	无法分析系统行为	暂时无法解决，只能尽量增加应用调用系统接口的日志
只能个案分析	个案问题基本上没有共同特征，无法归纳分析并解决；而且无法判定影响程度	结合线上数据协同分析，尝试解决一类问题，而不是一个问题扩展发现设备的途径，增加局域网扫码投屏功能，优化网络抖动等网络不稳定原因导致的无法找到TV设备扩展通信通道，增加远程投屏，建立广域网通信通道

批量分析方法

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

未来可期

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

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

各取所长：

电视的观影体验更好(大屏、高画质、好音效)，但是操控不够便捷；
手机的操控便捷，但是观影体验不如电视；

开疆拓土：打破边界、拉近距离，会产生更能多可能性。

远程投屏：将手机与电视的互动从局域网扩展到广域网，延伸了投屏的边界，同时拉近了人与人的距离，让你的手机可以连接父母的电视；
万物互联：物联网作为当下科技创新大潮中的一员，已经崭露头角。电视作为家庭的中心，手机作为个人的的延伸，已经通过投屏建立了连接，随着更多家用设备接入物联网，一定能借由投屏这座桥产生更多可能性。

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

本文分享自微信公众号 - 爱奇艺技术产品团队（iQIYI-TP）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。