fundo
Com a inovação contínua da tecnologia da Internet e o rápido desenvolvimento da indústria da televisão, assistir a vídeos online através da televisão tornou-se gradualmente um importante método de entretenimento para o público. Como um dos aplicativos com maior atividade do usuário em dispositivos de TV, o Kiwi App oferece uma variedade de serviços de reprodução de conteúdo para os usuários. Além disso, também oferece operações de adesão, eventos especiais e outros serviços que exigem eficiência online extremamente alta do usuário. Para atender às demandas deste último, investigamos as atuais tecnologias dinâmicas e cross-end: H5, Flutter e React Native e, finalmente, escolhemos a solução H5 do ponto de vista da eficiência de desenvolvimento, custo de mão de obra, capacidades dinâmicas e desempenho. a página H5 é responsável por lidar com um grande número de caixas, atividades operacionais, tópicos especiais e outros negócios no aplicativo Kiwi. No entanto, a principal dificuldade que enfrentamos é que a página H5 demora muito para carregar nos aparelhos de TV. Como melhorar a experiência do usuário das páginas H5 nos aparelhos de TV é um problema que precisamos resolver com urgência.
Desafios enfrentados
Desafio 1: O ciclo de substituição dos equipamentos de TV é longo e o problema de fragmentação do sistema é grave Atualmente, os equipamentos com sistema de TV abaixo de 5.0 representam cerca de 30%, o que é uma proporção muito elevada. A primeira coisa que a otimização enfrenta é a extensão das versões, e a compatibilidade com versões inferiores é a principal consideração. A figura a seguir mostra a proporção de versões do sistema de TV:
Desafio 2: O desempenho do equipamento de TV é baixo. O equipamento de TV é dividido principalmente em três tipos: TV, caixa e projetor. A configuração do equipamento acima é seriamente inferior à configuração de telefone móvel convencional do mesmo período. classificação, a CPU é um dispositivo de 4 A com arquitetura de núcleo A53 e mais de 1,5 G de memória pode ser classificado como um dispositivo de alto desempenho. Entre os dispositivos de baixo desempenho, ainda existem muitos dispositivos com processadores de arquitetura A7 ou 512 M de memória.
Desafio 3: As versões dos aplicativos estão seriamente fragmentadas Devido à complexidade da atual situação de cooperação na indústria de TV, muitos fabricantes de TV tradicionais buscam estabilidade e são mais cautelosos em relação às atualizações; quase não há manutenção após a venda. A complexidade do modelo de cooperação leva a muita customização e dificuldade de atualização, o que representa grandes desafios para otimização e lançamento no nível do SDK.
Processo de otimização
1. Preparação
Antes da otimização, o trabalho mais importante é unificar o calibre de desempenho e formular indicadores estatísticos. No nível do calibre, não pegamos o tempo convencional de carregamento da página front-end, mas adotamos um cenário mais alinhado com a experiência real do usuário: desde o momento em que o usuário clica no botão até o momento em que ele fica visível para o real do utilizador. Embora isto aumente o consumo global de tempo dos nossos indicadores estatísticos, após avaliação, este indicador é mais propício para a direcção do nosso trabalho de optimização subsequente. O calibre do indicador é explicado da seguinte forma
1) O tempo que leva para a página ficar visível: a partir do clique do cliente -> salto da página do cliente -> inicialização do contêiner da web -> a renderização do DOM front-end é concluída e visível.
2 ) O tempo interativo total: o tempo visível da página + o tempo total que pode responder ao botão do controle remoto do usuário.
3) Página nativa demorada: salto da página do cliente demorado.
4) Inicialização do Webview: A inicialização do contêiner da web é demorada.
5) Leva tempo para chamar h5: Leva tempo para executar a primeira linha de código de loadUrl para h5.
6) O tempo que leva para carregar h5: O tempo que leva para h5 começar a executar a primeira linha do código até que fique visível na página.
7) Leva tempo para que o h5 seja interativo: leva tempo para que a página h5 fique visível e responda.
Depois que os padrões estatísticos forem unificados, entregaremos os pontos de tempo acima no nível do webSDK, coletaremos dados on-line e realizaremos a otimização direcionada com base nas questões realimentadas pelos indicadores. Sem otimização, a velocidade de carregamento do H5 é em média de cerca de 5,5 segundos e a experiência do usuário é muito ruim. Através da análise de dados on-line, o tempo de carregamento do H5 ocupa uma grande proporção do total. A otimização do tempo de carregamento do H5 é um problema que precisamos resolver urgentemente.
2. Otimização do tempo de carregamento H5
O tempo de carregamento do H5 depende principalmente da otimização da parte front-end. Devido ao comprimento limitado do artigo, o trabalho convencional de otimização da página H5 não será descrito em detalhes, como:
2) Mesclagem de solicitação de dados
3) Otimização da lógica de negócios
4) Otimização da estrutura DOM
5) Carregamento de roteamento assíncrono em modos diferentes no mesmo endereço
3. Otimização de SSR
Além da otimização acima, a tecnologia SSR (pré-renderização do lado do servidor) surgiu à nossa vista. SSR é uma tecnologia que otimiza o desempenho de aplicativos da web e o SEO. Ao gerar HTML inicial no lado do servidor, melhora a velocidade de carregamento da página e. desempenho do mecanismo de pesquisa e experiência do usuário. Ao escolher a estrutura apropriada, criar rotas, escrever componentes, configurar o servidor e adquirir dados, os desenvolvedores podem implementar a renderização do lado do servidor, proporcionando aos usuários uma melhor experiência de aplicação web e garantindo uma renderização mais rápida da primeira tela.
Este método de redução da pressão de processamento no final é muito adequado para cenários onde o desempenho do equipamento final de TV é ruim. Embora o SSR também tenha suas próprias deficiências, por exemplo, embora possa melhorar a velocidade geral de carregamento da página, não conduz ao carregamento progressivo da página. Após repetidas experiências e dados online, continuamos a acreditar que os benefícios globais da RSS são positivos e lançámos investigação e desenvolvimento. Experimentos provaram que a solução SSR melhora significativamente a velocidade de carregamento das páginas H5.
O processo de carregamento da página H5 otimizado por meio de SSR é mostrado na figura abaixo:
Depois de otimizar as soluções front-end mencionadas acima, a velocidade de carregamento de cada versão foi significativamente melhorada. O tempo gasto na parte de renderização do H5 foi reduzido de uma média de 4 segundos para menos de 1,5 segundos, e o tempo total foi reduzido para cerca de 3,5 segundos. Neste momento, continuar a otimizar puramente do ponto de vista front-end encontrou um gargalo, e a relação entrada-saída também é baixa. É necessário continuar a pensar em métodos de otimização do ponto de vista geral do cliente.
4. Cache offline de recursos
O CDN implantará alguns recursos H5 importantes (como css, js, png, ttf, etc.), muitos dos quais permanecem inalterados durante o ciclo da versão front-end e são grandes, e o cliente fará o pré-download deles no momento apropriado . Ao renderizar a página, podemos usar o retorno de chamada shouldInterceptRequest do kernel WebView para interceptar a solicitação de carregamento do URL H5 online. Se o recurso não for encontrado no cache offline, ele será carregado através da rede online; encontrado no cache offline, ele será carregado diretamente. Leia os recursos do disco local e retorne ao WebView. Este método pode melhorar muito a velocidade de carregamento de recursos.
O fluxograma geral da solução de cache offline é o seguinte:
Ao mesmo tempo, durante o processo, descobrimos que a biblioteca de solicitação nativa do Android HttpUrlConnection em versões inferiores ainda está no estágio http1.0 e não pode aproveitar a otimização de http2.0 (como reutilização de canal), que faz a solicitação durante pré-carregamento demorado maior. Atualmente, há um grande número de dispositivos de versão inferior no lado da TV com versões abaixo de 5.0, por isso optamos por mudar para a biblioteca de rede desenvolvida de forma independente pelo lado da TV. Esta biblioteca de rede suporta http2.0, melhorando assim o desempenho da solicitação de. dispositivos de versão baixa. Além disso, vemos que existe um determinado tempo de agendamento do sistema desde o momento em que o usuário clica até a abertura da página H5. Esse tempo também pode ser utilizado para otimização, ou seja, o carregamento paralelo mencionado abaixo.
5. Carregamento paralelo
Além das soluções mencionadas acima para armazenar JS/CSS e outros recursos em cache antecipadamente, o armazenamento antecipado de páginas HTML também é um método de otimização comum na indústria. Antes da página ser SSR, esse mecanismo de armazenamento em cache não alcançou bons resultados porque o. o gargalo de desempenho não está no download de dados HTML. Após o SSR da página, esse método entrou em nosso campo de visão novamente. Após a geração dos dados de renderização, esse mecanismo de cache pode, teoricamente, desempenhar um papel maior.
Mas, ao mesmo tempo, encontramos outras dificuldades. Como os algoritmos personalizados têm sido amplamente utilizados nos negócios, o método de armazenar páginas em cache antecipadamente e manter o conteúdo inalterado por um determinado período de tempo formou um conflito com o requisito comercial de manter a página. dados atualizados em tempo real. Isto exige que encontremos soluções técnicas otimizadas e mais adequadas aos cenários de negócio.
O sistema Android consumirá tempo do sistema ao fazer a troca de salto de página de atividade. Esse consumo de tempo é inversamente proporcional ao desempenho do dispositivo. Interceptamos o clique do usuário na página da web durante a troca de salto de página para iniciar a tarefa antecipadamente e carregar o SSR do. Página H5 em dados paralelos. Em seguida, um token exclusivo é gerado com base nos parâmetros de URL e cookie. Quando chegar a hora de realmente renderizar o WebView, redirecione a URL para o cache. Ao mesmo tempo, a sincronização de bloqueio multi-thread e mecanismos de tempo limite são usados para melhorar ainda mais a velocidade de carregamento do H5.
O fluxograma geral da solução de carregamento paralelo é o seguinte:
Depois de concluir essas otimizações, nossa velocidade de carregamento continuou otimizada de 3,5 segundos para cerca de 2,8 segundos, um aumento de cerca de 23%. Após uma série de medidas de otimização mencionadas acima, nosso tempo de carregamento do H5 foi reduzido da média inicial de 5,5 segundos para cerca de 2,8 segundos. No entanto, em comparação com páginas nativas puras (nativas), ainda há uma grande lacuna na velocidade de carregamento e precisamos continuar buscando métodos de otimização mais eficazes. Para melhorar ainda mais a experiência do utilizador, fizemos várias tentativas técnicas e, através da comunicação ativa e da cooperação com outras equipas técnicas, temos novas ideias.
6. Pré-aquecimento do recipiente
Quando o APP é iniciado e o thread principal está ocioso, podemos pré-aquecer o mecanismo WebView e construir um pool de cache WebView, para que o contêiner pré-aquecido possa ser reutilizado e a velocidade de carregamento do WebView possa ser melhorada. Esta estratégia de otimização visa principalmente dispositivos de médio a alto desempenho e dispositivos de baixo desempenho com grande memória. Quando o dispositivo está ocioso, pré-aquecemos o contêiner WebView e adicionamos o contêiner pré-aquecido ao pool de cache.
Em nosso uso subsequente, obtemos o contêiner WebView pré-aquecido diretamente do pool de cache do WebView. Isso economiza tempo na criação de contêineres da web e jscore.
7. Pré-renderização de página
O H5 do lado da TV tem muitas restrições de cenário de negócios em tempo real, principalmente atividades operacionais que são muito sensíveis ao tempo, o que impõe certas restrições à nossa otimização. No entanto, encontramos alguns cenários que podem ser personalizados e otimizados. Por exemplo, quando usuários não-membros assistem a conteúdo exclusivo para membros, geralmente há um período de teste gratuito de 6 minutos. Após o término do período de teste, eles pularão automaticamente. para H5. Este tipo de cenário nos proporciona vantagens naturais para a pré-renderização. Em cenários semelhantes, a pré-renderização é acionada automaticamente quando a contagem regressiva começa, permitindo que o conteúdo H5 seja carregado antecipadamente e alcançando o efeito de abertura instantânea do H5. Conforme mostrado no GIF abaixo, a imagem superior é o processo de carregamento sem otimização, e você pode ver a tela preta óbvia e o processo de carregamento é o resultado da otimização de pré-renderização, alcançando um verdadeiro lançamento segundo a segundo;
Depois de completar as medidas de otimização acima e comparar os dados do mesmo período do ano passado, podemos perceber pelos dados online que o tempo de carregamento foi ainda mais reduzido, passando da média inicial de 5,5 segundos em cenários não SSR e 3,5 segundos em SSR cenários para a média atual de 2 segundos Melhorou significativamente a experiência do usuário.
Conquistas
Conduzimos experimentos AB sobre otimização no final. Os dados de teste após a divisão e a média mostraram que nossas medidas de otimização aumentaram a taxa de conversão da página de geração de pedidos em cerca de 21% em média, e a taxa de conversão da taxa de sucesso de pagamento também aumentou em média 2,4%.
As experiências provaram que melhorar a velocidade de carregamento e a experiência do utilizador nas principais páginas comerciais tem um impacto positivo muito direto nos negócios, o que também nos proporciona confiança e motivação suficientes para continuar a promover a otimização no futuro.
plano futuro
No futuro, esperamos encontrar mais maneiras de reduzir ainda mais os indicadores de desempenho, controlar o tempo médio da página para menos de 2 segundos e controlar a degradação.
Além disso, notamos que os dados médios não refletem totalmente a experiência real do usuário. Alguns usuários finais ainda enfrentam uma experiência de usuário ruim. Continuaremos a analisar a situação real encontrada pelos usuários após o percentil 90 e a realizar a otimização direcionada. Ao mesmo tempo, continuaremos a realizar otimizações personalizadas para cenários de negócios importantes, como o caixa, para melhorar ainda mais a velocidade de carregamento dos principais negócios, melhorando assim continuamente a experiência do usuário e a conversão de negócios.
Talvez você também queira ver
Este artigo é compartilhado pela conta pública do WeChat - iQIYI Technology Product Team (iQIYI-TP).
Se houver alguma violação, entre em contato com [email protected] para exclusão.
Este artigo participa do “ Plano de Criação da Fonte OSC ”. Você que está lendo é bem-vindo para participar e compartilhar juntos.
