Die Entwicklung der Projektion von Kiwi-Früchten

Wuhan Yuan Chuanghui kehrt zurück, sprechen wir am 20. April über große Models.“

Anmerkung des Autors: Kiwi Screen Mirroring hat sich mit Kiwi TV bis 2022 entwickelt und mehr als 3 Millionen täglich aktive Benutzer erreicht. Sowohl Benutzer als auch wir haben höhere Anforderungen und höhere Anforderungen an die Funktionen und Leistung der Bildschirmspiegelung gestellt, sodass es beginnen wird Im Jahr 2022 wurden die Funktion und Leistung der Bildschirmprojektion systematisch erweitert und optimiert. Dieser Artikel basiert auf der TV-Seite und stellt Ihnen die Schwierigkeiten und Lösungen vor, mit denen Sie bei der Optimierung der Bildschirmprojektion auf der iQiyi-Site konfrontiert sind. Wir sind offen für Ihre Korrekturen und Vorschläge.

Überprüfung des Optimierungsprozesses

Seit der Übernahme der Bildschirmprojektionsfunktion Anfang 2022 haben wir sukzessive Arbeiten wie Funktionserweiterungen und Effizienzverbesserungen bei der Fehlerbehebung durchgeführt. Bis Ende 2022 waren wir immer noch der Meinung, dass die Iterations- und Problembehandlungseffizienz der Bildschirmprojektionsfunktion verbessert wurde nicht hoch. Als Brücke zwischen Mobiltelefonen und Fernsehern stellt die Screencasting-Funktion hohe Anforderungen an ihre Zuverlässigkeit und Stabilität. Nur wenn wir eine solide Grundlage schaffen, können wir einen stetigen und langfristigen Fortschritt erzielen. Daher haben wir den Prozess der Screencasting-Optimierung ins Leben gerufen Screencasting-Dienste und Online-Daten Wir suchen nach umfassenden Lösungen für die drei Hauptprobleme der .

Problem 1: Der Screencasting-Dienst ist instabil

Um eine maximale Verfügbarkeit zu gewährleisten, muss der Bildschirmspiegelungsdienst unabhängig vom Clientprozess funktionieren. Daher muss er von einem Unterprozess gestartet werden, um Online-Probleme flexibler iterieren und beheben zu können. Daher wird ein unabhängiges Plug-In verwendet. Obwohl die historische Version der Screencasting-Dienstarchitektur die beiden oben genannten Punkte unterstützen kann, kann die verwendete Einzeldienstlösung (der Screencasting-Dienst wird über ModuleManager beim Client registriert) die bidirektionale Kommunikationsstabilität von Screencasting und Screencasting nicht gut unterstützen Serviceüberwachung und Bleiben Sie am Leben.

Die neue Lösung verfügt über ein Dual-Service-Design und basiert auf dem Binder-Mechanismus des Android-Systems, der den Peer-Status stabil und zuverlässig erfassen und den Verbindungsstatus überwachen kann. Verwenden Sie Bind und Start, um den Dienst gleichzeitig zu starten, um die Priorität des Screencasting-Prozesses zu erhöhen, bessere Keep-Alive-Effekte zu erzielen und stabilere bidirektionale Kommunikationsfunktionen bereitzustellen.

Problem 2: Online-Daten sind nicht verfügbar

In der alten Architektur des Bildschirmprojektionsdienstes kann die Datenverwaltung nicht den gesamten Prozess abdecken, was dazu führt, dass die gemeldeten Daten unvollständig sind, die Online-Qualität des Bildschirmprojektionsdienstes nicht überwacht werden kann und Online-Probleme nicht analysiert und gelöst werden können.

Die neue Architektur des Bildschirmprojektionsdienstes ist mit drei Ebenen der Bereitstellungsüberwachung ausgestattet:

Betriebs- und Zuverlässigkeitsüberwachung des Bildschirmprojektions-Servicemoduls
Start und Ergebnisse des Screencasting-Protokolls
Schritte zum Pushen des Links

Jede Ebene richtet einen entsprechenden Sitzungsmechanismus für Geschäftssitzungen ein. Jeder Geschäftsprozess generiert eine eindeutige Sitzungs-ID als Sitzungskennung, die den gesamten Geschäftslogik-Lebenszyklus verbindet und entsprechende Geschäftsdaten an jedem Schlüsselknoten als Grundlage für die Online-Datenanalyse meldet.

Servicemodul für Bildschirmprojektion

Das Entwurfsziel auf dieser Ebene besteht darin, die Gesamtzuverlässigkeit von Screencasting, Servicefunktionen und Prozess-Keep-Alive, Wiederholungsversuchen und erneuter Verbindung sowie anderer Datenerfassung sicherzustellen und zu verbessern.

Dieses Modul vervollständigte die Sammlung von Keep-Alive-Statusinformationen für Online-Geräteprozesse, deckte und verifizierte die Gründe für die Instabilität der alten Architektur und implementierte gezielte Vermeidung in der neuen Version. wie:

Durch Datenrückmeldung aufgedeckte Probleme	Vermeidungs- und Verbesserungslösungen
Die startService-Methode startet den untergeordneten Prozess. Die Prozesspriorität ist niedrig, der Prozess kann leicht recycelt werden und führt zu häufigen Neustarts.	Fügen Sie die Bind-Methode hinzu, um die Prozesspriorität zu erhöhen
Der Start des Geräteprozesses mit geringer Leistung dauert lange und höhere Versionen von Android lösen ANR-Ausnahmen aus (Service.startForeground wird nicht rechtzeitig aufgerufen).	Starten Sie den Dienst im Bindungsmodus und fügen Sie nach Erfolg startService hinzu.
Die Implementierung des Plug-In-Mechanismus ist fehlerhaft und die Prozessprioritätskontrolle des Flag-Parameters von bindService geht verloren, was dazu führt, dass der untergeordnete Prozess recycelt wird.	Verlassen Sie im Plug-in-Modus den Unterprozessmodus und führen Sie den Bildschirmspiegelungsdienst im Hauptprozess aus
Der LMK-Mechanismus einiger Roms ist streng, um den im Vordergrund sichtbaren Hauptprozess am Leben zu erhalten, um den untergeordneten Prozess mit höherer Priorität aufrechtzuerhalten.	Verlassen Sie bei problematischen Geräten den Unterprozessmodus und wechseln Sie den Screencasting-Dienst in den Hauptprozessmodus.

Screencasting-Protokoll gestartet

Die Kernfunktionspunkte des Bildschirmprojektionsdienstes liegen auf der Protokollebene und der Netzwerkebene. Die Entwurfsziele dieser Ebene bestehen darin, das Bildschirmprojektionsprotokollmodul zu starten und die Ergebnisse zu verfolgen, Änderungen im Systemnetzwerk zu überwachen und das Bildschirmprojektionsprotokoll neu zu starten Modul rechtzeitig zu installieren, um sicherzustellen, dass der Bildschirmprojektionsdienst im neuen Netzwerk verfügbar ist.

Nach der Überprüfung und Verbesserung hat dieses Modul die Überwachung des Screencasting-Protokollstarts und die Statistik der Fehlergründe abgeschlossen und die Netzwerkkarten- und Verbindungsinformationen jedes Online-Geräts sowie die Verteilung der Protokollstartfehler in jedem Eingangsszenario zur Analyse gesammelt und zusammengefasst und Verbesserung Die Erfolgsrate des Protokollstarts liefert Quelldaten und Optimierungsfeedback. Online-Analysen und Lösungen für bestehende Probleme sind wie folgt:

Durch Datenrückmeldung aufgedeckte Probleme	Vermeidungs- und Verbesserungslösungen
Netzwerkänderungsszenario, Erfolgsquote beim Protokollstart ist niedrig	Unter normalen Umständen befindet sich das Gerätenetzwerk bei einem Netzwerkwechsel bereits in einem instabilen Zustand und lässt sich vorerst nicht vermeiden.
Der Prozess bleibt im Hintergrund bestehen, das Gerät wird in den Ruhezustand versetzt und aktiviert, wodurch das Netzwerk geschlossen und geöffnet wird. Es werden häufig Netzwerkänderungen ausgelöst und das Protokollmodul neu gestartet.	Durch die verzögerte Verarbeitung von Netzwerkänderungsereignissen können einige abnormale Szenarien vermieden werden. Diese Verzögerung kann jedoch nicht genau sein, den Zeitraum, in dem das Netzwerk nicht bereit ist, nicht vollständig vermeiden und Szenarien mit kurzer Aktivierungszeit und ruhendem Netzwerk nicht bewältigen. Versuchen Sie, Startfehler ohne IPv4 zu vermeiden, basierend auf dem Vorhandensein von Netzwerkkarten und IPs beim Start.
Bei einigen Geräten sind gleichzeitig zwei Netzwerkkarten angeschlossen, WLAN löst häufig eine Trennung und erneute Verbindung aus und das Bildschirmprojektionsprotokollmodul startet häufig neu und die Fehlerrate steigt.	Optimieren Sie die Auswahlstrategie für Netzwerkkarten und geben Sie Netzwerkkarten mit aktiven Netzwerktypen im System Vorrang, um häufige Neustarts von Protokollmodulen aufgrund der abwechselnden Auswahl verschiedener Netzwerkkarten zu vermeiden.
Einige Geräte konnten das aktive Netzwerk des Systems nicht abrufen oder verfügten über kein Netzwerk. Tatsächlich war das Netzwerk verfügbar und erhielt einige Übermittlungen ohne Netzwerkfehlercode.	Optimieren Sie die Strategie zur Auswahl der Netzwerkkarte. Das aktive Netzwerk des Systems wird nur als Referenz verwendet. Wenn die Netzwerkkarte und der IP-Status verfügbar sind, fahren Sie mit dem Starten des Protokollmoduls fort.

Push-Link-Link

Zu diesem Link gehört, dass das Fernsehgerät die Push-Anfrage empfängt, die Daten und lokalen Fähigkeiten überprüft, die Startdaten vorab zwischenspeichert, die Schnittstelle für die Wiedergabe startet, jede Phase und die Renderzeit des ersten Frames aufzeichnet usw.

Mithilfe dieser statistischen Datenebene ist es möglich, Qimo-Screencasting- und DLNA-Screencasting-Fehler und -Schäden an jeder Verbindung, den Zeitaufwand für die einzelnen Phasen, die Erfolgsquote beim Start und die Startzeit usw. zu analysieren. Die Optimierungspunkte des Filmförderungsprozesses sind wie folgt:

Durch Datenrückmeldung aufgedeckte Probleme	Vermeidungs- und Verbesserungslösungen
Verbindungsverlust beim prozessübergreifenden Pullup	Rufen Sie zur Geräteanpassung prozessübergreifend auf und wechseln Sie in den Hauptprozessmodus, um den Start neuer Prozesse zu vermeiden.
Verbindungsverlust während der Aktivitätsstartphase	Der Start der Hintergrundaktivität ist beschädigt und Systemeinschränkungen können nicht vermieden werden, indem wir Benutzer dazu anleiten, die Kiwi-App im Voraus zu öffnen.
Verbindungsverlust beim Rendern des ersten Frames	Die Renderrate des ersten Frames hängt von der Erfolgsrate der Wiedergabe und den Ressourcen des Film-Pushs ab und kann nicht auf Push-Link-Ebene gelöst werden.
Qimo Screencasting zeitaufwändige Optimierung	Optimieren und löschen Sie für Qimo-Screencasting-Szenarien die Schnittstellenaufrufe im Link-Link, koordinieren Sie sie mit der iQiyi-App, fügen Sie erforderliche Informationsfelder hinzu und vermeiden Sie das Anfordern von Schnittstellen beim Pushen von Filmen.

System zur Anzeige der Bildschirmprojektion

Richten Sie ein Bulletin Board für das Qualitätssystem für Bildschirmprojektionen ein, achten Sie auf die Trendänderungen wichtiger Indikatoren nach der Einführung der neuen Version und vergleichen Sie diese im gleichen Zeitraum mit der alten Version. Dazu gehören die Starterfolgsrate des Screencasting-Dienstes, die Starterfolgsrate des Screencasting-Protokolls, die durchschnittliche Zeit, die benötigt wird, um mit der Ausstrahlung von Qimo-Videos zu beginnen usw.

Beispiele für Problemerkennung und -analyse

5.1 Startfehler und Optimierungsprozess des Screen Mirroring Protocol SDK

1) Problemerkennung

Zu Beginn jeder Veröffentlichung wird die Erfolgsquote des Bildschirmspiegelungs-SDK üblicherweise unter 90 % fallen, wie unten gezeigt

2) Analysieren Sie die Gründe

Es muss einen Grund für die Anomalie geben. Nachdem wir die Bereitstellungsdaten des SDK-Starts für die Bildschirmspiegelung während des Problemzeitraums analysiert und anhand der Gerätedimension eingestuft haben, haben wir festgestellt, dass das SDK-Startfehlerproblem die folgenden Merkmale aufweist:

Die Gerätemodelle sind relativ konzentriert, und die beiden Modelle MagicBox_M20C/A tragen 80 % der Fehler bei.
Geräte-IDs sind relativ konzentriert und lösen häufig Probleme aus. Die Geräte-IDs, die bei beiden Modellen Probleme auslösen, machen nur 3–4 % ihrer DAU aus.

Schwierigkeiten bei der Reproduktion:

Es gibt keine zwei Geräte in der Testgerätebibliothek
Es handelt sich allesamt um ältere Modelle und der Kauf von Geräten ist nicht mehr möglich.

Wir können nur eine eingehende Analyse der Start- und Protokollstartdatensequenzen einzelner Geräte durchführen, um Gemeinsamkeiten zu finden. Wir haben stichprobenartig mehrere seriöse Geräte-IDs überprüft und Folgendes festgestellt:

Wenn der Fehler auftritt, ist das aktive Netzwerk des Systems verkabelt und mit dem WLAN verbunden. Das WLAN sendet häufig Änderungsbenachrichtigungen.
Beim Starten des Protokolls werden abwechselnd eth0 und wlan0 ausgewählt. Änderungen an der Netzwerkkarte führen zu häufigen Neustarts des SDK, was zu einer großen Anzahl von Startfehlern führt. Das kürzeste Intervall kann jeweils 6 Sekunden betragen.
Die Anzahl der abnormalen Geräte ist nicht groß, aber die Menge der generierten abnormalen Daten ist groß.

Daraus können wir das Szenario ableiten, in dem das Problem auftritt:

Wenn sowohl die kabelgebundene Netzwerkkarte als auch die drahtlose Netzwerkkarte verbunden sind, benachrichtigt das ROM der beiden Geräte Tmall Magic Box M20A/C das WLAN-Netzwerk regelmäßig (Intervall <5 Sekunden), um die Verbindung zu trennen oder erneut herzustellen.
Die alte Netzwerkkartenauswahlstrategie von Kiwi besteht darin, der WLAN-Netzwerkkarte Vorrang einzuräumen. In diesem Szenario werden die kabelgebundene Netzwerkkarte und die drahtlose Netzwerkkarte abwechselnd verwendet und das Bildschirmspiegelungs-SDK wird neu gestartet.
Zu diesem Zeitpunkt, während der Netzwerkänderungsperiode, ist der Status der Netzwerkkarte instabil und ein häufiger Start erhöht die Wahrscheinlichkeit eines Startfehlers des Bildschirmspiegelungs-SDK.

3) Optimierungsplan und Datenüberprüfung

Aktualisieren und passen Sie die Netzwerkkarten-Auswahlstrategie an, fügen Sie eine neue Netzwerkkarten-Auswahlstrategie hinzu und unterstützen Sie den Cloud-Konfigurationswechsel zwischen alten und neuen Strategien, um den Datenvergleich zwischen verschiedenen Strategien zu erleichtern:

Priorisieren Sie die aktive Netzwerkkarte des Systems
Das kabelgebundene Netzwerk hat Vorrang vor WLAN

支持新选网卡策略的版本上线后,云配控制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源创计划”，欢迎正在阅读的你也加入，一起分享。