1. Introdução
No trabalho, tive que lidar repetidamente com a escolha de tecnologia adequada para o desenvolvimento móvel. Abaixo, tentei coletar e classificar os principais frameworks de acordo com as abordagens utilizadas, vantagens e desvantagens.
Se algumas das minhas informações estiverem incorretas ou desatualizadas - comentários são bem-vindos.
Qualquer estrutura de plataforma cruzada é uma camada de abstração acima da plataforma nativa e permite acessar apenas os recursos diretamente suportados pela estrutura.
Na maioria dos casos, é possível expandir o suporte à plataforma escrevendo plugins nativos para a estrutura, mas em alguns casos isso pode complicar significativamente o desenvolvimento. Um novo exemplo do sensacional artigo do AirBnb é o React Native, que no momento não sabe como trabalhar com as bibliotecas Android de 64 bits.
Você também precisa prestar atenção em que os plugins nativos e o código principal de um aplicativo de plataforma cruzada são executados em diferentes processos e a interação entre eles pode causar problemas de desempenho. Para trabalhar com sensores, ou SQLite, isso geralmente não é um problema, mas se você usar, digamos, a biblioteca OpenCV como um plug-in nativo e começar a lançar vídeo entre ele e o aplicativo principal, a desaceleração pode ser significativa.
Oferta limitada no mercado de trabalho
Em primeiro lugar, a própria presença de desenvolvedores depende da prevalência da estrutura. Encontrar pessoas no React Native pode ser ainda mais fácil do que os desenvolvedores nativos, mas, por exemplo, com o Flutter é muito mais difícil.
Quanto esse fator precisa ser levado em consideração depende das tarefas. A maioria das startups pode não prestar atenção, pois aprender uma nova tecnologia provavelmente é um bônus para os funcionários existentes e potenciais. Por outro lado, as grandes empresas são forçadas a levar em consideração o mercado de trabalho.
Riscos de suporte
Acredita-se que a probabilidade de que o suporte à estrutura de plataforma cruzada termine seja muito maior que a probabilidade do mesmo evento com relação ao sistema operacional móvel.
De fato, a questão é bastante complicada. O sistema operacional pode ser fechado como estruturas (o exemplo do Windows Phone é completamente novo). Além disso, dentro do desenvolvimento nativo, certas tecnologias também podem ser fechadas e, às vezes, o código nas estruturas de plataforma cruzada é mais persistente.
Um exemplo disso é no campo de jogos e multimídia - a Apple enviará a tecnologia OpenGL para o SO e todos que escreverem aplicativos 3D nativos terão que reescrevê-los completamente para lançar novas versões. Ao mesmo tempo, para aqueles que usaram mecanismos de jogos de plataforma cruzada (por exemplo, Unity), a atualização não exigirá nenhum esforço adicional.
As principais direções
Desenvolvimento híbrido, HTML + JavaScript
Tecnicamente, aplicativos do tipo híbrido são páginas HTML exibidas em um navegador incorporado. Em geral, a estrutura não é necessária para essa abordagem, mas o Cordova fornece um conjunto de plug-ins para acessar os recursos da plataforma, e é por isso que eles geralmente são usados.
Principais vantagens
Custo mínimo de desenvolvimento
A abordagem híbrida permite reutilizar não apenas as habilidades dos desenvolvedores, mas também o código escrito para sites.
Capacidade de integrar elementos da web
O número de bibliotecas para HTML / JS excede significativamente o número de bibliotecas para aplicativos nativos. Do interessante, isso inclui, por exemplo, o Google Analytics ou uma ampla seleção de redes de anúncios.
Principais Contras
Baixa produtividade
O próprio JavaScript moderno usa a compilação JIT, é bem otimizado e funciona rapidamente, mas a construção de uma interface baseada na árvore DOM não é um processo muito eficiente. O uso de estruturas JS modernas fornece um nível adicional de carga. Para telefones fracos e / ou com o uso ativo de elementos interativos, isso pode ser um problema.
"Sentimento nativo"
Este é um ponto bastante informal, mas muito importante. O site no navegador responde a gestos e exibe um pouco diferente de um aplicativo móvel. O elemento mais notável desse sentimento, um atraso de 300ms quando pressionado, decide Cordova, mas muitos outros detalhes permanecem.
Problema de compatibilidade do navegador
Nas versões mais antigas do Android (anteriores à versão 5), o WebView fazia parte da plataforma e não era atualizado automaticamente. Consequentemente, não será possível usar os recursos modernos do navegador em aplicativos híbridos nesses dispositivos.
Como resultado, os aplicativos híbridos limitam a versão mínima do Android (deixando para trás cerca de 13% dos dispositivos no momento) ou incluem o WebView no código do aplicativo (projeto CrossWalk), aumentando o tamanho do aplicativo em várias dezenas de megabytes.
Destino
Crie rapidamente aplicativos únicos. Se houver um orçamento substancial para o desenvolvimento, uma abordagem híbrida geralmente é desdém.
Estruturas básicas
O núcleo de todas as principais estruturas híbridas é o Cordova, que fornece acesso a plugins nativos. O PhoneGap fornece ferramentas para construir sobre o Cordova, enquanto o Ionic é uma estrutura e um conjunto de componentes para criar interfaces de usuário nele.
UI nativa, código comum
É importante observar que, com essa abordagem, a interface do usuário e a lógica de negócios são executadas em diferentes processos, interagindo por meio de uma ponte. Várias desvantagens da abordagem estão associadas a isso.
Essa abordagem possui várias opções de implementação.
Classificação do código executável
Código compilado
O Xamarin usa a linguagem C #, compilando-a no código da plataforma nativa. Em geral, essa abordagem fornece um tamanho de aplicativo bastante pequeno e uma velocidade bastante alta.
Linguagem interpretada com compilação JIT
A maioria das estruturas nessa abordagem usa JavaScript para processar a lógica de negócios.
Classificação pelo método de descrição da interface
Ferramentas nativas
O Xamarin não apenas usa componentes de interface nativos, mas também os descreve no formato aceito para cada plataforma.
Elementos universais da interface
O Xamarin Forms e o Appcelerator usam seu próprio conjunto de widgets, que é convertido nos componentes de interface apropriados de cada plataforma.
O React Native usa wrappers em torno dos componentes da interface nativa. Por conseguinte, a interface é descrita para cada plataforma separadamente, mas o método de descrição é o mesmo.
Principais vantagens
Interface completamente nativa
Em primeiro lugar, a aparência e o "toque" do aplicativo coincidem completamente com os aplicativos nativos.
Em segundo lugar, permite o uso de bibliotecas de interface nativas em aplicativos. O uso de anúncios nativos (Anúncios Nativos), focados em aplicativos para celular, em outras abordagens não funcionará. É verdade que, para essa abordagem, o conjunto de bibliotecas relevantes é muito limitado. Eu sei apenas sobre o suporte a anúncios nativos do Facebook no React Native.
Capacidade de reutilizar as habilidades do desenvolvedor
Muitas estruturas deste grupo foram projetadas para que desenvolvedores de outras áreas possam aprender como criar aplicativos móveis com custos mínimos. Para React, Native é React, para Xamarin, .NET etc.
Principais Contras
Limitação dos recursos da interface ou custos adicionais para desenvolvimento separado
O formato deste menos depende da classificação da estrutura de acordo com a maneira como a interface é descrita:
O Xamarin permite que você use quase todos os recursos das plataformas, mas você precisa gastar muito tempo nas interfaces de cada plataforma. Como resultado, os custos de mão-de-obra não são muito inferiores aos do desenvolvimento nativo.
O Xamarin Forms e o Appcelerator permitem descrever interfaces apenas uma vez, mas funcionam com um subconjunto muito limitado de funcionalidade nativa (não mais do que a interseção mínima dos conjuntos de recursos de cada plataforma, para ser formal).
O React Native está no meio, combinando as duas deficiências, mas de forma menos pronunciada.
Desempenho de interação da interface
Aqui entra em jogo o fator de execução de interfaces e lógica de negócios em diferentes processos. Quando é necessário trocar grandes volumes de informações através de uma ponte em alta velocidade (animação complexa com alta frequência), podem surgir dificuldades nessa abordagem.
Vazamentos de memória
Vazamentos de memória podem ocorrer em qualquer aplicativo, mas a maioria das situações padrão é tratada por coletores de lixo.
O problema com aplicativos de plataforma cruzada com uma interface nativa é novamente que eles são executados em dois processos que possuem coletores de lixo separados. Se o objeto de lógica de negócios se referir a um objeto de interface, esse objeto de interface não será lixo, porque há um link para ele da ponte. Se o objeto de interface fizer referência novamente ao objeto de lógica de negócios, eles não serão considerados lixo, mesmo que não haja mais referências a eles.
As chances de encontrar um problema e sua escala dependem diretamente do aplicativo. Se os objetos associados à interface forem criados e excluídos ativamente (como na rolagem sem fim), a probabilidade de um vazamento aumenta. Se esses objetos forem grandes (por exemplo, imagens), o efeito do vazamento aumentará.
Na verdade, esse problema também está presente ao trabalhar com plug-ins nativos, que também são executados em um processo separado. Mas, na maioria dos casos, não existe uma manipulação intensiva de objetos grandes ou a interação ocorre em uma abordagem estritamente processual, sem referências cruzadas.
Destino
Aplicativos com uma interface totalmente nativa, especialmente se houver especialistas em tecnologias relacionadas.
Estruturas básicas
Reagir nativo
Possui suporte para o Facebook e usa a abordagem da estrutura React JS mais popular, devido à qual é muito popular. Um artigo recente sobre o abandono do React Native pela AirBnb fez muito barulho, mas, se consciente dos riscos, pode ser uma solução muito eficaz.
Xamarin
Além da abordagem principal, possui a biblioteca Xamarin.Forms, que permite projetar interfaces simples de forma eficiente e multiplataforma. Ativamente suportado pela Microsoft. Ao trabalhar com o ASP.NET no servidor, ele permite salvar adicionalmente uma certa quantidade de trabalho através do uso de classes comuns de lógica de negócios no servidor e no aplicativo móvel.
Nativecript
Ele é modelado no React Native para desenvolvedores que possuem outras estruturas JS (Angular e Vue.js). Menos popular, mas possui várias soluções mais modernas em arquitetura.
UI nativa, código comum
Quase todos os mecanismos de jogos usam essa abordagem, mas estão além do escopo deste artigo.
O princípio dessa abordagem é que o aplicativo use seu próprio código e sua própria renderização da interface do usuário.
Principais vantagens
Interfaces de alto desempenho
De fato, um aplicativo que desenha sua própria interface por si só executa as mesmas operações que o sistema operacional na interface nativa. Em teoria, pode ser ainda mais rápido, porque não há alternância entre o processo e o kernel, mas, na prática, outros fatores afetam a velocidade de renderização de uma interface específica, desempenham um papel muito maior.
"Interfaces de design"
Os aplicativos nativos usam componentes de interface prontos e têm algumas limitações sobre o que pode ser feito com eles. Por sua vez, os aplicativos que desenham sua própria interface não possuem essas restrições e podem misturar livremente elementos prontos com renderização individual.
Principais Contras
Essas desvantagens são relevantes apenas para aplicativos que imitam a interface padrão do sistema operacional. Como já mencionado, para interfaces de design e jogos, essa abordagem é ideal.
Tamanho da aplicação
Os aplicativos com essa abordagem são forçados a transportar código para renderizar todos os elementos da interface, incluindo os condicionalmente padrão. Isso afeta o tamanho do aplicativo durante a instalação e a RAM durante a operação.
Se o primeiro problema puder ser minimizado com o Tree Shaking eficaz (como as versões mais recentes do Flutter), esses aplicativos perdem de maneira estável a memória nativa da RAM. No entanto, esse problema também é característico de outras estruturas de plataforma cruzada.
Interface nativa
Por padrão, o aplicativo tem a mesma aparência em todas as plataformas, o que pode criar desconforto para os usuários. Os temas são usados para resolver esses problemas, mas não podem criar a sensação de um aplicativo totalmente nativo.
Mas há um ponto negativo maior - com essa abordagem, é mais difícil usar elementos de interface de terceiros criados para aplicativos nativos (incluindo os anúncios nativos mencionados anteriormente).
Destino
Aplicativos públicos, especialmente com uma interface de design.
Estruturas básicas
Flutter
O Flutter está sendo promovido pelo Google como a principal estrutura de desenvolvimento de plataforma cruzada e a interface para o seu futuro Fuscia OS. Embora a estrutura seja muito jovem (no estágio Preview da versão) e não muito comum, ela está rapidamente ganhando popularidade. Usa a linguagem Dart (com compilação no código nativo).
Ele tem todos os prós e contras da juventude - uma arquitetura bem pensada, levando em conta os erros de seus antecessores, mas um ecossistema bastante limitado.
QT Mobile
É popular entre os desenvolvedores de desktop QT. JavaScript pode ser usado no desenvolvimento. Sem o apoio de grandes empresas não é muito popular.
Kivy
Outra estrutura não muito popular que é interessante, principalmente porque é a única estrutura na lista que usa Python. Para desenvolvedores familiarizados apenas com esse idioma (e existem muitos em algumas áreas da tecnologia da informação), isso pode ser crucial.
Materiais relacionados
Na memória no Xamarin e estruturas semelhantes
Comparação de desempenho de aplicativos nativos, Flutter e React Native