A evolução da projeção de tela de kiwi

Wuhan Yuan Chuanghui retorna, vamos falar sobre modelos grandes em 20 de abril”

Nota do autor: O Kiwi Screen Mirroring foi desenvolvido com a Kiwi TV até 2022 e atingiu mais de 3 milhões de usuários ativos diariamente. Tanto os usuários quanto nós apresentamos mais demandas e requisitos mais elevados para as funções e desempenho do espelhamento de tela, então ele começará. em 2022 A função e o desempenho de projeção da tela foram sistematicamente expandidos e otimizados. Este artigo é baseado no lado da TV e apresenta as dificuldades e soluções enfrentadas no processo de otimização da projeção da tela no site iQiyi. Estamos abertos a suas correções e sugestões.

Revisão do processo de otimização

Desde que assumimos a função de projeção de tela no início de 2022, realizamos sucessivamente trabalhos como expansão de funções e melhoria da eficiência de solução de problemas. Até o final de 2022, ainda sentíamos que a eficiência de iteração e tratamento de problemas da função de projeção de tela era. não alto. Como uma ponte entre telefones celulares e TVs, a função de screencasting tem altos requisitos para sua confiabilidade e estabilidade. Somente estabelecendo uma base sólida podemos alcançar um progresso constante e de longo prazo . serviços de screencasting e dados online Buscamos soluções completas para os três principais problemas de .

Problema 1: o serviço de screencasting está instável

Para garantir a máxima disponibilidade, o serviço de espelhamento de tela precisa sobreviver independentemente do processo do cliente, por isso é iniciado por um subprocesso. Para iterar e corrigir problemas online com mais flexibilidade, ele precisa ser implantado e atualizado de forma independente. então ele usa um plug-in independente. Embora a versão histórica da arquitetura do serviço de transmissão de tela possa suportar os dois pontos acima, a solução de serviço único adotada (o serviço de transmissão de tela é registrado para o cliente por meio do ModuleManager) não pode suportar bem a estabilidade da comunicação bidirecional de transmissão de tela, transmissão de tela monitoramento de serviço e permanecer vivo.

A nova solução adota um design de serviço duplo e é baseada no mecanismo Binder do sistema Android, que pode detectar de forma estável e confiável o status dos pares e monitorar o status da conexão. Use Bind e Start para iniciar o serviço ao mesmo tempo para aumentar a prioridade do processo de screencasting para obter melhores efeitos de manutenção de atividade e fornecer recursos de comunicação bidirecional mais estáveis.

Problema 2: os dados online não estão disponíveis

Na antiga arquitetura do serviço de projeção de tela, o gerenciamento de dados não pode cobrir todo o processo, resultando em dados relatados incompletos, incapacidade de monitorar a qualidade online do serviço de projeção de tela e incapacidade de analisar e resolver problemas online.

A nova arquitetura do serviço de projeção de tela foi projetada com três níveis de monitoramento de entrega:

Operação do módulo de serviço de projeção de tela e monitoramento de confiabilidade
Inicialização e resultados do protocolo de screencasting
Etapas para enviar o link

Cada nível estabelece uma sessão de negócios correspondente. Mecanismo de sessão. Cada processo de negócios gera um SessionId exclusivo como identificador de sessão, que conecta todo o ciclo de vida da lógica de negócios e relata os dados de negócios correspondentes em cada nó-chave como base para a análise de dados on-line.

Módulo de serviço de projeção de tela

O objetivo do design neste nível é garantir e melhorar a confiabilidade geral do screencasting, funções de serviço e manutenção de processos, novas tentativas e reconexão e outras coletas de dados.

Este módulo completou a coleta de informações de status de keep-alive do processo de dispositivo on-line, expôs e verificou os motivos da instabilidade da arquitetura antiga e implementou a prevenção direcionada na nova versão. como:

Problemas expostos pelo feedback de dados	Soluções de prevenção e melhoria
O método startService inicia o processo filho. A prioridade do processo é baixa e o processo é facilmente reciclado e causa reinicializações frequentes.	Adicione o método Bind para aumentar a prioridade do processo
O processo do dispositivo de baixo desempenho leva muito tempo para iniciar e versões superiores do Android acionarão exceções ANR (Service.startForeground não é chamado a tempo)	Inicie o serviço no modo Bind e adicione startService após sucesso.
A implementação do mecanismo de plug-in está com defeito e o controle de prioridade do processo do parâmetro flag do bindService é perdido, fazendo com que o processo filho seja reciclado.	No modo plug-in, abandone o modo de subprocesso e execute o serviço de espelhamento de tela no processo principal
O mecanismo LMK de algumas Rom é estrito. Quando a memória está limitada, para manter vivo o processo filho com maior prioridade, o processo principal visível em primeiro plano pode ser eliminado.	Para dispositivos problemáticos, abandone o modo de subprocesso e mude o serviço de screencasting para o modo de processo principal.

Protocolo de screencasting iniciado

Os principais pontos de função do serviço de projeção de tela estão na camada de protocolo e na camada de rede. Os objetivos de design deste nível são iniciar o módulo de protocolo de projeção de tela e rastrear os resultados, monitorar alterações na rede do sistema e reiniciar o protocolo de projeção de tela. módulo em tempo hábil para garantir que o serviço de projeção de tela esteja disponível na nova rede.

Após verificação e melhoria, este módulo concluiu o monitoramento da inicialização do protocolo de screencasting e estatísticas dos motivos de falha, e coletou e resumiu a placa de rede e as informações de conexão de cada dispositivo online, e a distribuição das falhas de inicialização do protocolo em cada cenário de entrada, para análise e melhoria. A taxa de sucesso de inicialização do protocolo fornece dados de origem e feedback de otimização. A análise online e as soluções para os problemas existentes são as seguintes:

Problemas expostos pelo feedback de dados	Soluções de prevenção e melhoria
Cenário de mudança de rede, a taxa de sucesso de inicialização do protocolo é baixa	Em circunstâncias normais, a rede do dispositivo já está num estado instável quando a rede é alterada e não pode ser evitada por enquanto.
O processo sobrevive em segundo plano e o dispositivo dorme e é ativado, fazendo com que a rede seja fechada e aberta. Ele acionará frequentemente alterações de rede e reiniciará o módulo de protocolo. A rede não está pronta quando é ativada pela primeira vez.	O processamento atrasado de eventos de mudança de rede pode evitar alguns cenários anormais, mas esse atraso não pode ser preciso, não pode evitar completamente o período em que a rede não está pronta e não pode lidar com cenários em que o tempo de ativação é curto e a rede está inativa. Com base na presença de placas de rede e IPs na inicialização, tente eliminar falhas de inicialização sem IPv4.
Alguns dispositivos têm placas de rede duplas conectadas ao mesmo tempo, o WIFI frequentemente aciona a desconexão e a reconexão, e o módulo de protocolo de projeção de tela reinicia frequentemente e a taxa de falhas aumenta.	Otimize a estratégia de seleção de placas de rede e dê prioridade às placas de rede com tipos de rede ativos no sistema para evitar reinicializações frequentes de módulos de protocolo devido à seleção alternada de diferentes placas de rede.
Alguns dispositivos não conseguiram obter a rede ativa do sistema ou não tinham rede. Na verdade, a rede estava disponível e recebeu alguma entrega sem código de erro de rede.	Otimize a estratégia de seleção da placa de rede A rede ativa do sistema é usada apenas como referência. Quando a placa de rede e o status do IP estiverem disponíveis, continue para iniciar o módulo de protocolo.

Link de envio

Este link inclui o recebimento da solicitação push pela TV, a verificação dos dados e dos recursos locais, o pré-armazenamento em cache dos dados de inicialização, o lançamento da interface para reprodução, a gravação de cada estágio e o tempo de renderização do primeiro quadro, etc.

Através deste nível de dados estatísticos, é possível analisar falhas e danos no screencasting Qimo e DLNA em cada link, consumo de tempo de estágio, taxa de sucesso de inicialização e tempo de inicialização, etc. Os pontos de otimização do processo de promoção do filme são os seguintes:

Problemas expostos pelo feedback de dados	Soluções de prevenção e melhoria
Perda de link no pullup entre processos	Aumente os processos para adaptação do dispositivo e mude para o modo de processo principal para evitar o início de novos processos.
Perda de link durante a fase de inicialização da atividade	A inicialização da atividade em segundo plano está danificada e as restrições do sistema não podem ser evitadas. Ao orientar os usuários a abrir o aplicativo Kiwi com antecedência, podemos evitar o cenário de inicialização em segundo plano.
Perda de link na renderização do primeiro quadro	A taxa de renderização do primeiro quadro está relacionada à taxa de sucesso da reprodução e aos recursos do push do filme e não pode ser resolvida no nível do push link.
Qimo screencasting otimização demorada	Para cenários de screencasting Qimo, otimize e exclua as chamadas de interface no link, coordene com o aplicativo iQiyi, adicione campos de informações necessários e evite solicitar interfaces ao enviar filmes.

Sistema indicador de projeção de tela

Estabeleça um quadro de avisos para o sistema de qualidade de projeção de tela, preste atenção às mudanças de tendência de indicadores importantes após o lançamento da nova versão e compare-a com a versão antiga no mesmo período. Isso inclui a taxa de sucesso de inicialização do serviço de screencasting, a taxa de sucesso de inicialização do protocolo de screencasting, o tempo médio necessário para iniciar a transmissão de vídeos Qimo, etc.

Exemplos de descoberta e análise de problemas

5.1 Falha na inicialização do SDK do protocolo de espelhamento de tela e processo de otimização

1) Descoberta de problemas

No início de cada lançamento, a taxa de sucesso do SDK de espelhamento de tela normalmente cairá abaixo de 90%, conforme mostrado abaixo

2) Analise os motivos

Deve haver um motivo para a anormalidade. Depois de analisar os dados de entrega da inicialização do SDK de espelhamento de tela durante o período do problema e classificá-los com base na dimensão do dispositivo, descobrimos que o problema de falha de inicialização do SDK tem as seguintes características:

Os modelos de dispositivos são relativamente concentrados, e os dois modelos MagicBox_M20C/A contribuem com 80% dos erros.
Os IDs de dispositivos são relativamente concentrados e disparam com frequência. Os IDs de dispositivos que desencadeiam problemas para os dois modelos representam apenas 3-4% de sua DAU.

Dificuldades encontradas na reprodução:

Não há dois dispositivos na biblioteca de equipamentos de teste
São todos modelos mais antigos e não é mais possível adquirir equipamentos.

Só podemos realizar uma análise aprofundada da inicialização do serviço de projeção de tela e das sequências de dados de entrega de inicialização do protocolo de dispositivos individuais, a fim de encontrar pontos em comum. Verificamos aleatoriamente vários IDs de dispositivos sérios e descobrimos que:

Quando ocorre a falha, a rede ativa do sistema está cabeada e conectada ao wifi. O wifi envia frequentemente notificações de alteração.
Ao iniciar o protocolo, eth0 e wlan0 são selecionados alternadamente. Alterações na placa de rede causam reinicializações frequentes do SDK, resultando em um grande número de falhas de inicialização. O intervalo mais curto pode ser de 6 segundos de cada vez.
O número de dispositivos anormais não é grande, mas a quantidade de dados anormais gerados é grande.

A partir disso podemos inferir o cenário onde o problema ocorre:

Quando a placa de rede com fio e a placa de rede sem fio estão conectadas, a ROM dos dois dispositivos Tmall Magic Box M20A/C notificará frequentemente (intervalo <5s) a rede WIFI para desconectar ou reconectar.
A antiga estratégia de seleção de placa de rede do Kiwi é dar prioridade à placa de rede wifi. Nesse cenário, a placa de rede com fio e a placa de rede sem fio serão usadas alternadamente e o SDK de espelhamento de tela será reiniciado.
Neste momento, durante o período de mudança de rede, o status da placa de rede é instável e a inicialização frequente aumenta a probabilidade de falha na inicialização do SDK de espelhamento de tela.

3) Plano de otimização e verificação de dados

Atualize e ajuste a estratégia de seleção de placa de rede, adicione uma nova estratégia de seleção de placa de rede e suporte à alternância de configuração em nuvem entre estratégias antigas e novas para facilitar a comparação de dados entre diferentes estratégias:

Priorize a placa de rede ativa do sistema
Rede cabeada tem prioridade sobre 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源创计划”，欢迎正在阅读的你也加入，一起分享。