キウイフルーツスクリーンプロジェクションの進化

著者注: Kiwi Screen Mirroring は、2022 年まで Kiwi TV で開発され、毎日 300 万人を超えるアクティブユーザーに達しました。ユーザーと私たちの両方が、画面ミラーリングの機能とパフォーマンスに対して、より多くの要求とより高い要件を提示したため、開始されます。 2022年スクリーン投影機能とパフォーマンスを計画的に拡張および最適化しました。この記事はテレビ側に基づいて、iQiyi サイトの画面投影を最適化する過程で直面する困難と解決策を紹介します。修正や提案をお待ちしています。

最適化プロセスのレビュー

2022年初頭に画面投影機能を引き継いで以来、機能拡張やトラブルシューティングの効率化などの作業を順次実施してきましたが、2022年末時点ではまだ画面投影機能のイテレーションや問題対応の効率化が課題であると感じていました。高くない。携帯電話とテレビの間の架け橋として、スクリーンキャスト機能には信頼性と安定性に対する高い要求があり、強固な基盤を築くことによってのみ、安定した長期的な進歩を達成することができます。そのため、私たちは不安定なスクリーンキャストを最適化するプロセスを開始しました。スクリーンキャストサービスとオンラインデータの利用不能とオンライントラブルシューティングの効率の低さという 3 つの主要な問題に対する徹底的な解決策を追求します。

問題 1: スクリーンキャストサービスが不安定である

最大限の可用性を確保するには、画面ミラーリングサービスはクライアントプロセスから独立して存続する必要があるため、オンラインの問題をより柔軟に反復して修正するには、サブプロセスによって開始され、独立して展開およびアップグレードする必要があります。そのため、独立したプラグインを使用します。スクリーンキャストサービスアーキテクチャの過去のバージョンでは、上記 2 点をサポートできますが、採用されている単一サービスソリューション (スクリーンキャストサービスは ModuleManager を通じてクライアントに登録されます) では、スクリーンキャスト、スクリーンキャストの双方向通信の安定性を十分にサポートできません。サービス監視とStay live。

新しいソリューションはデュアルサービス設計を採用しており、Android システムの Binder メカニズムに基づいており、安定かつ確実にピアのステータスを検知し、接続ステータスを監視できます。バインドと開始を使用してサービスを同時に開始すると、スクリーンキャストプロセスの優先順位が上がり、キープアライブ効果が向上し、より安定した双方向通信機能が提供されます。

問題 2: オンラインデータが利用できない

古いスクリーン投影サービスのアーキテクチャでは、データ管理がプロセス全体をカバーできず、レポートされるデータが不完全になり、スクリーン投影サービスのオンライン品質を監視できなくなり、オンラインの問題を分析して解決できなくなります。

新しい画面投影サービスアーキテクチャは、次の 3 つのレベルの配信監視を備えて設計されています。

画面投影サービスモジュールの動作と信頼性の監視
スクリーンキャストプロトコルの起動と結果
リンクをプッシュする手順

各レベルは、対応するビジネスセッションセッションメカニズムを確立し、セッション ID として一意の SessionId を生成します。これにより、ビジネスロジックのライフサイクル全体が接続され、オンラインデータ分析の基礎として各キーノードで対応するビジネスデータが報告されます。

スクリーン投影サービスモジュール

このレベルの設計目標は、スクリーンキャスト、サービス機能、プロセスのキープアライブ、再試行と再接続、その他のデータ収集の全体的な信頼性を確保し、向上させることです。

このモジュールは、オンラインデバイスプロセスのキープアライブステータス情報の収集を完了し、古いアーキテクチャの不安定性の理由を明らかにして検証し、新しいバージョンで対象を絞った回避を実装しました。のように：

データフィードバックによって明らかになった問題	回避策と改善策
startService メソッドは子プロセスを開始します。プロセスの優先順位は低く、プロセスは簡単にリサイクルされ、頻繁に再起動されます。	Bind メソッドを追加してプロセスの優先度を上げる
低パフォーマンスのデバイスプロセスは開始に時間がかかり、Android の上位バージョンでは ANR 例外がトリガーされます (Service.startForeground が時間内に呼び出されません)。	Service をバインドモードで開始し、成功したら startService を追加します。
プラグイン機構の実装に欠陥があり、bindService の flag パラメータのプロセス優先度制御が失われ、子プロセスがリサイクルされてしまいます。	プラグインモードでは、サブプロセスモードを放棄し、メインプロセスで画面ミラーリングサービスを実行します。
一部の 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 の 2 つのモデルがエラーの 80% を占めています。
デバイス ID は比較的集中しており、頻繁に発生します。この 2 つのモデルの問題を引き起こすデバイス ID は、DAU の 3 ～ 4% にすぎません。

再現時に発生する困難:

テスト機器ライブラリには 2 つのデバイスはありません
これらはすべて古いモデルであり、機器を購入することはできなくなりました。

共通点を見つけるには、個々のデバイスの画面投影サービスの起動とプロトコル起動の配信データシーケンスを詳細に分析するしかありません。いくつかの重要なデバイス ID をランダムにチェックしたところ、次のことがわかりました。

障害が発生すると、システムのアクティブなネットワークが有線で Wi-Fi に接続され、変更通知が頻繁に送信されます。
プロトコルを開始するときに、eth0 と wlan0 が交互に選択され、ネットワークカードが変更されると SDK が頻繁に再起動され、その結果、毎回の起動に非常に多くの失敗が発生する可能性があります。
異常な機器の数は多くありませんが、発生する異常データの量は多くなります。

これから、問題が発生するシナリオを推測できます。

有線ネットワークカードと無線ネットワークカードの両方が接続されている場合、2 つのデバイスの 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源创计划”，欢迎正在阅读的你也加入，一起分享。