Quero compartilhar a experiência de desenvolver um aplicativo com a exibição de conteúdo de vídeo para SmartTV (Tizen e WebOS) e quais problemas encontramos.
Nas TVs modernas, como sabemos, você pode instalar aplicativos diferentes para facilitar o trabalho com alguns recursos e conteúdo. Na maioria dos casos, esses aplicativos são um navegador normal; na televisão, é o Chromium.
Como este é um navegador, nada nos impediu de usar o React.js para desenvolvimento, o que afetou alguns problemas de desempenho.
Não falarei exatamente sobre como você precisa fazer com os exemplos de código, falarei sobre as nuances e decisões que foram tomadas.
Vamos ver os principais pontos:
- Recursos limitados
- Navegação
- Estilos de desempenho e renderização
- Leitores de vídeo
- Backend
Recursos limitados
Não há tanta memória e desempenho na TV quanto em nossos computadores; portanto, o primeiro problema é a limitação de recursos.
Por exemplo, apenas cerca de 250 megabytes para uso são alocados para o aplicativo e encontramos um problema que, ao exibir uma grade com conteúdo (imagem, descrição, classificação), a memória pode ser gasta no limite, quando existem apenas 1000 elementos na grade e rolamos para baixo e o tamanho da imagem aumenta e aumenta e, em algum momento, o aplicativo trava com a inscrição de que a memória acabou.
A solução para este problema é
react-windowEle não armazena todos os elementos fora da janela no DOM.
Navegação
Se, em um computador, estamos acostumados a clicar nos elementos do site, nas televisões, usamos um controle remoto que também pode ser usado como mouse, mas a maioria desses botões são botões. O problema de navegação surge daqui, que devemos processar os pressionamentos de botão do controle remoto e navegar por todo o aplicativo sem o cursor, mas ao mesmo tempo precisamos processar o clique nos elementos com um "clique".
Alguns códigos de botão nos controles remotos da LG e Samsung são diferentes e também do teclado usual, portanto, para cada plataforma, tínhamos códigos de botão codificados que processamos.
Exemplo de Tizen
Tizen
export default { KEY_0: 48, KEY_1: 49, KEY_2: 50, KEY_3: 51, KEY_4: 52, KEY_5: 53, KEY_6: 54, KEY_7: 55, KEY_8: 56, KEY_9: 57, KEY_UP: 38, KEY_DOWN: 40, KEY_LEFT: 37, KEY_RIGHT: 39, KEY_OK: 13, KEY_BACK: 10009, KEY_CHANNEL_UP: 427, KEY_CHANNEL_DOWN: 428, KEY_MEDIA_FAST_FORWARD: 417, KEY_MEDIA_PAUSE: 19, KEY_MEDIA_PLAY: 415, KEY_MEDIA_PLAY_PAUSE: 10252, KEY_MEDIA_REWIND: 412, KEY_MEDIA_STOP: 413, KEY_DEBUG_TOGGLE_CONSOLE: 403, KEY_DEBUG_TOGGLE_QUICK_EDIT: 404, KEY_DEBUG_SET_FAVOURITES: 405, KEY_DEBUG_CLEAR_FAVOURITES: 406, KEY_SHOW_REMOTE_POINTER: 7777777,
WebOS
export default { KEY_0: 48, KEY_1: 49, KEY_2: 50, KEY_3: 51, KEY_4: 52, KEY_5: 53, KEY_6: 54, KEY_7: 55, KEY_8: 56, KEY_9: 57, KEY_UP: 38, KEY_DOWN: 40, KEY_LEFT: 37, KEY_RIGHT: 39, KEY_OK: 13, KEY_BACK: 461, KEY_MEDIA_FAST_FORWARD: 417, KEY_MEDIA_PAUSE: 19, KEY_MEDIA_PLAY: 415, KEY_MEDIA_PLAY_PAUSE: 10252, KEY_MEDIA_REWIND: 412, KEY_MEDIA_STOP: 413, KEY_CHANNEL_UP: 33, KEY_CHANNEL_DOWN: 34, KEY_DEBUG_SET_EMAIL: 403, KEY_DEBUG_TOGGLE_CONSOLE: 404, KEY_DEBUG_TOGGLE_QUICK_EDIT: 405, KEY_DEBUG_SET_FAVOURITES: 406, KEY_DEBUG_CLEAR_FAVOURITES: 407, KEY_SHOW_REMOTE_POINTER: 1536, KEY_HIDE_REMOTE_POINTER: 1537, };
Teclado
export default { KEY_0: 48, KEY_1: 49, KEY_2: 50, KEY_3: 51, KEY_4: 52, KEY_5: 53, KEY_6: 54, KEY_7: 55, KEY_8: 56, KEY_9: 57, KEY_UP: 38, KEY_DOWN: 40, KEY_LEFT: 37, KEY_RIGHT: 39, KEY_OK: 13, KEY_BACK: 8,
Como você pode ver, no teclado são botões com letras (indicadas nos comentários).
Para lidar com a navegação clicando nos botões e clicando com o mouse, sempre tivemos o resultado de um evento - mouseClick, processando todos os eventos da mesma maneira.
Outra característica da navegação é o foco, em cada tela deve haver um elemento em foco, porque, perdendo o foco, não poderemos mais navegar na tela. Cada elemento recebeu as propriedades de foco e identificação do foco. Ao navegar, sempre foi necessário levar isso em conta, mas também, às vezes, é necessário retornar ao restaurar o estado da tela completamente anterior, portanto a navegação foi escrita completamente personalizada.
Estilos de desempenho e renderizações
A animação em CSS funciona lentamente nas TVs, especialmente quando há muitos elementos DOM que entram na animação, você pode ver não uma mudança suave, mas uma apresentação de slides. Uma solução para esse problema é a tela. O desenho, animação e iluminação durante a navegação aceleram o trabalho várias vezes, mas se você tiver automação, eles podem não gostar dessa implementação, porque é difícil para eles verificar o conteúdo da imagem.
Muita renderização na página é outra dor, tudo começa a desacelerar, se contrair. Era necessário controlar esse processo o máximo possível, após o qual o componente deveriaComponentUpdate se parecer com o seguinte:
Como resultado, reescrevemos as partes sensíveis do aplicativo no vanilla js, tornando-o mais rápido.
Leitores de vídeo
LG e Samsung têm diferentes players de vídeo, o que também cria dificuldades adicionais de desenvolvimento. Para a LG, uma tag de vídeo é usada, para o Samsung AVPlay sdk. Portanto, existem diferenças na funcionalidade, é preciso ter em mente que nem todos os recursos são iguais e podem variar de versão para versão do SO.
Também houve problemas com a carga ao iniciar o vídeo - ele foi resolvido com cache, paralelização e adiamento de solicitações, processamento.
Backend
A velocidade do back-end, a velocidade de processamento de solicitações e seu número afeta a velocidade do trabalho. O lado FE deve ter uma quantidade mínima de processamento de dados. Se você precisar carregar grandes quantidades de dados, poderá usar trabalhadores da Web.