Prefácio
Nos últimos anos, a adaptação multi-terminal baseada na Web de vários sites está em pleno andamento, e soluções que dependem de várias tecnologias também foram desenvolvidas entre as indústrias. Como o design responsivo baseado na consulta de mídia CSS3 nativa do navegador, a solução de "adaptação em nuvem" baseada em re-progresso inteligente da nuvem, etc. Este artigo discute principalmente soluções de adaptação multi-terminais com base na separação das extremidades dianteiras e traseiras.
Sobre separação front-end
Em relação à solução de separação front-end, há uma explicação muito clara em "Pensamento e prática de separação front-end com base nos nodejs (i)". Introduzimos o NodeJS como a camada de renderização entre a interface do servidor e o navegador. Como a camada NodeJS está completamente separada dos dados e não precisa se preocupar com muita lógica de negócios, é muito adequada para o trabalho de adaptação multi-terminal nessa camada.
Detecção de UA
A primeira coisa a resolver na adaptação multi-terminal é o problema de detecção da UA. Para uma solicitação, precisamos saber o tipo deste dispositivo para produzir o conteúdo correspondente a ele. Atualmente, existem bibliotecas de recursos do agente de usuário muito maduras e ferramentas de detecção compatíveis com um grande número de dispositivos no mercado. Aqui está uma lista compilada por Mozilla. Entre eles, existem aqueles que estão sendo executados no lado do navegador e os que estão sendo executados na camada de código lateral do servidor. Algumas ferramentas fornecem módulos Nginx/Apache, responsáveis por analisar as informações da UA para cada solicitação.
Na verdade, recomendamos o último. A solução baseada na separação do front-end determina que a sonda UA só pode ser executada no lado do servidor, mas não é uma solução suficientemente amigável se o código da sonda e a biblioteca de recursos estiverem acoplados no código comercial. Aumentamos esse comportamento para a frente e penduramos no Nginx/Apache. Eles são responsáveis por analisar as informações da UA para cada solicitação e, em seguida, passá -las para o código comercial através do cabeçalho HTTP.
Existem vários benefícios em fazer isso:
Nosso código não precisa mais prestar atenção em como as passas de UA, basta retirar as informações analisadas da camada superior. Se houver vários aplicativos no mesmo servidor, as informações da UA analisadas pelo mesmo NGINX poderão ser usadas juntas, economizando a perda de resolução entre diferentes aplicativos.
Solução de detecção de UA com base no Nginx compartilhado por tmall
O Tengine Web Server do Taobao também fornece um módulo semelhante NGX_HTTP_USER_AGENT_MODULE.
Vale ressaltar que, ao escolher ferramentas de detecção de UA, a manutenção da biblioteca de recursos deve ser considerada. Como existem cada vez mais novos tipos de equipamentos no mercado, cada dispositivo terá um agente de usuário independente, portanto, a biblioteca de recursos deve fornecer boas estratégias de atualização e manutenção para se adaptar à mudança de equipamento.
Várias adaptações incorporadas no modo MVC
Após obter as informações da UA, precisamos considerar se a adaptação do terminal é realizada com base no UA especificado. Mesmo na camada NodeJS, embora a maior parte da lógica de negócios esteja faltando, ainda dividimos os internos em três modelos: modelo/controlador/visualização.
Vamos primeiro usar o diagrama acima para analisar algumas soluções de adaptação multi-terminais existentes.
Adaptações construídas no controlador
Esta solução deve ser a maneira mais simples e rude de lidar com isso. Passe o mesmo URL para a mesma camada de controle através do roteador. A camada de controle distribui dados e modela a lógica para a exibição correspondente (exibição) por meio de informações da UA para renderização, e a camada de renderização fornece modelos que se adaptam a vários terminais de acordo com pré-consultões.
A vantagem desta solução é que ela mantém a unidade de dados e camadas de controle, e a lógica de negócios pode ser aplicada a todos os terminais apenas uma vez. No entanto, esse cenário é adequado apenas para aplicativos de baixa interativa, como páginas de exibição. Uma vez que o negócio é mais complexo, os controladores de cada terminal podem ter sua própria lógica de processamento. Se eles ainda compartilharem um controlador, ele tornará o controlador muito inchado e difícil de manter, o que é sem dúvida uma escolha errada.
Adaptações construídas no roteador
Para resolver os problemas acima, podemos distinguir dispositivos no roteador e distribuí -los a diferentes controladores para diferentes terminais:
Esta também é uma das soluções mais comuns, principalmente manifestadas no uso de um conjunto separado de aplicações para diferentes terminais. Por exemplo, quando a página inicial do PC Taobao e a versão WAP da página inicial do Taobao, quando diferentes dispositivos visitam www.taobao.com, o servidor será redirecionado para a versão WAP da página inicial do Taobao ou a versão para PC do Taobao Homepage através do controle de roteador. São dois conjuntos de aplicações completamente independentes.
No entanto, essa solução, sem dúvida, traz o problema que os dados e parte da lógica não podem ser compartilhados. Vários terminais não podem compartilhar os mesmos dados e lógica de negócios, resultando em muito trabalho repetitivo e é ineficiente.
Para aliviar esse problema, alguém propôs uma solução otimizada: no mesmo conjunto de aplicativos, cada fonte de dados ainda é abstraída em cada modelo e fornecida aos controladores de diferentes terminais para combinação:
Esta solução resolve o problema que os dados anteriores não podem ser compartilhados. No controlador, cada terminal ainda é independente um do outro, mas pode usar o mesmo lote de fontes de dados juntos. Pelo menos não há necessidade de desenvolver interfaces independentes para tipos de terminais nos dados.
Nas duas soluções baseadas em roteador acima, devido à independência do controlador, cada terminal pode implementar uma lógica interativa diferente para suas próprias páginas, garantindo flexibilidade suficiente para cada terminal, o que também é a principal razão pela qual a maioria dos aplicativos adota essa solução.
Adaptações construídas na camada de visualização
Esta é a solução usada para páginas de pedidos do Taobao, mas a diferença é que a página de pedidos coloca a camada geral de renderização no lado do navegador, em vez da camada NodeJS. No entanto, seja um navegador ou nodejs, a ideia geral de design ainda é a mesma:
Nesta solução, roteador, controlador e modelo não precisam prestar atenção às informações do dispositivo, e o julgamento do tipo de terminal é completamente deixado na camada de exibição para processamento. O módulo principal da figura é "View Factory". Depois que o modelo e o controlador passam os dados e a lógica de renderização, eles usam a fábrica de visualização para pegar componentes específicos de vários componentes predefinidos com base em informações do dispositivo e em outros estados (não apenas informações da UA, mas também ambiente de rede, área do usuário etc.) e combine -os na página final.
Esta solução tem várias vantagens:
A camada superior não precisa prestar atenção às informações do dispositivo (UA). Os vídeos de vários terminais ainda são tratados pela camada de visualização que mostra o melhor relacionamento. Não é apenas a adaptação multi-terminal, mas, além das informações da UA, cada componente de exibição também pode determinar qual modelo ele produz de acordo com o status do usuário, como ocultar imagens por padrão em baixas velocidades de rede e banners de atividades de saída em áreas designadas. Diferentes modelos de cada componente de visualização podem decidir se deve usar os mesmos dados e lógica de negócios a seu próprio critério, fornecendo um método de implementação muito flexível.
Mas é óbvio que essa solução também é a mais complexa, especialmente ao considerar alguns cenários de aplicativos interativos, o roteador e o controlador podem não ser capazes de permanecer tão puros. Especialmente para algumas empresas com integridade relativamente forte, que não podem ser divididas nos próprios componentes, essa solução pode não ser aplicável; E para alguns negócios simples, o uso dessa arquitetura pode não ser a melhor escolha.
Resumir
As soluções acima são refletidas em uma ou mais partes do modelo MVC. Se uma solução não atender às necessidades dos negócios, várias soluções poderão ser adotadas ao mesmo tempo. Ou pode-se entender que a complexidade e os atributos interativos nos negócios determinam para qual solução de adaptação multi-terminal para a qual o produto é mais adequado.
Comparado com o esquema de design responsivo baseado no navegador, porque a maioria da lógica de detecção e renderização de terminais é migrada para o servidor, a adaptação na camada NodeJS, sem dúvida, traz melhor desempenho e experiência do usuário; Além disso, em comparação com os problemas de qualidade de conversão causados por alguns esquemas de "adaptação em nuvem", eles não existirão no esquema "personalizado" com base na separação front-end. A solução de adaptação para a separação das extremidades frontal e traseira tem vantagens naturais nesses aspectos.
Finalmente, para se adaptar a necessidades de adaptação mais flexíveis e poderosas, as soluções de adaptação baseadas na separação front-end enfrentarão mais desafios!