Problemas potenciais
Eu recomendo fortemente que você evite adicionar bibliotecas externas ao seu projeto. No entanto, isso não significa que o uso de bibliotecas seja nocivo, e seu arquivo Gradle deve ser completamente limpo de quaisquer dependências externas! Quero transmitir a ideia de que uma análise muito séria precisa ser feita antes de adicionar uma nova biblioteca. Para entender como analisar bibliotecas, vamos dar uma olhada nos problemas potenciais que você pode enfrentar ao adicionar uma nova biblioteca ao seu projeto.
Tamanho do aplicativo
A maioria das bibliotecas não aumenta muito o tamanho do seu aplicativo. Mas existem tais libs, depois de adicioná-las, sua aplicação aumentará significativamente! Por exemplo, a biblioteca Realm pode aumentar o tamanho do APK de 4 MB para 12 MB. Em média, o aplicativo pesa de 100 MB a 200 MB e os 8 MB extras podem não ser perceptíveis. Mas tenha em mente que o Realm não é a única biblioteca que afeta negativamente o tamanho do APK. É possível reduzir o tamanho do APK usando essa dependência? Sim, você pode dividir o apk por arquiteturas de processador. Mas isso leva ao próximo problema (ponto 2).
Manutenção do código
Os projetos crescem, são cobertos com cada vez mais lógica e às vezes fica mais difícil entendê-los. Para que, após vários anos de desenvolvimento do projeto, qualquer novo desenvolvedor possa se acostumar facilmente com o projeto, é necessária uma arquitetura de projeto clara. No entanto, algumas bibliotecas podem anular a sustentabilidade do projeto. Por exemplo, o trabalho incorreto com EventBus pode confundir muito a lógica de seu aplicativo. É importante distinguir claramente entre onde e em quais casos você usa esta biblioteca. E também para ter certeza de que ninguém jamais se desviará dessas regras. Mas o que acontece na prática? Quase todo desenvolvedor começando com EventBus o usa em qualquer lugar. Como resultado, o projeto se torna completamente ilegível.
É hora de explorar a biblioteca
Ao adicionar uma nova biblioteca, você precisa aprender como interagir com ela. Existem bibliotecas que podem ter um impacto muito negativo na velocidade de desenvolvimento no futuro.
Por exemplo, a PagingLibrary do Google se esforça muito para descobrir como interagir com ela. Cada novo desenvolvedor levará de 12 a 20 horas para descobrir essa biblioteca. Você está perdendo quase 3 dias! Em apenas 3 dias, você pode anotar sua paginação e ser independente de soluções de terceiros.
Velocidade de construção
A velocidade de construção de aplicativos modernos é fraca. No entanto, se você quiser aumentar seu tempo de construção ainda mais - use Dagger ! Não sei por que a biblioteca ainda é usada ativamente após o advento de Kotlin. Na maioria dos casos, Dagger contém todos os 4 problemas descritos acima.
Bugs, bugs, bugs ...
Na minha experiência, em apenas um projeto, serrei 5 bibliotecas devido à presença de bugs nelas. Lembre-se de que quase sempre existem bugs nas bibliotecas. Por exemplo:
- AndroidPdfViewer deixa vazamentos de memória, lida incorretamente alguns casos com nulo, o que faz com que um NullPointerException seja lançado
- O Android Navigation Component não funciona corretamente com animações Elemant Compartilhado em alguns casos
- Cicerone às vezes trava o aplicativo devido a
executePendingTransactions()
Isso significa que não vale a pena usar bibliotecas? Não, as bibliotecas podem e devem ser usadas, mas é importante pelo menos ter certeza de que não há bugs críticos para o seu projeto na lista de problemas.
Vulnerabilidades na biblioteca
Você conhece a maneira mais fácil de hackear vários aplicativos de uma vez examinando apenas um código-fonte? Precisamos encontrar um bug em uma grande biblioteca que é usada por muitos desenvolvedores. E por meio dessa vulnerabilidade para obter acesso aos dados de seu aplicativo. Se você não estiver desenvolvendo um aplicativo que requeira maior atenção à segurança do usuário, feche os olhos a este ponto. Caso contrário, procure um problema que resolva as vulnerabilidades potenciais.
Suporte de biblioteca
Se a biblioteca não foi atualizada por um ano, pergunte se vale a pena usá-la. O fato é que existem bugs nas bibliotecas regularmente. Se esses bugs não forem corrigidos, vale a pena usar esta biblioteca? É bem possível que em um futuro próximo você se depare com um bug de biblioteca e terá que procurar maneiras alternativas de implementar o recurso. Existem algumas bibliotecas que precisam se adaptar aos recursos da API Android atual. Por exemplo, se um novo elemento apareceu no Android, você precisa adicionar suporte para ele. Essas bibliotecas incluem Anko , que não é mais compatível. Agora não faz sentido usar esta biblioteca em grandes projetos.
A biblioteca está presente em todas as camadas do projeto
Bibliotecas como RxJava ou PagingLibrary forçam o desenvolvedor a usar sua API em todas as camadas do aplicativo. Se você tem certeza de que a biblioteca sempre estará no projeto, não há problema. Mas se por algum motivo você tiver que cortar a biblioteca, então gastará esforços colossais! Você terá que reescrever metade do projeto.
Limitações da biblioteca
Cada lib fornece uma API limitada pela disponibilidade de métodos públicos e implementação interna. Certifique-se de que os recursos da biblioteca sejam totalmente suficientes para você. Por exemplo, a popular biblioteca Android Navigation Component é muito prática para os desenvolvedores. Ele não fornece métodos de exibição, ocultação e adição (que a FragmentTransaction possui). Além disso, a biblioteca complica o trabalho com BottomNavigationView quando é necessário armazenar o histórico das guias.
Grande arquivo Gradle com dependências
Quando chego a um novo projeto, a primeira coisa que faço é olhar as dependências no arquivo Gradle. Ele deixa claro o que o aplicativo pode fazer e como certas tarefas são resolvidas. Mas fiquei surpreso quando vi que OkHttp, Retrofit e Volley (fork) são usados para trabalhar com a rede. E isso é apenas networking. O próprio arquivo Gradle consiste em um grande número de bibliotecas, cujo suporte terminou há muito tempo. Quando um desenvolvedor está sozinho, ele pode manter todo o projeto em sua cabeça, mas quando novos desenvolvedores chegam, torna-se extremamente difícil entender tal projeto.
Lista de verificação de perguntas antes de implementar a biblioteca
- Qual é o problema desta biblioteca? Eles são essenciais para o meu projeto?
- Quão testada é esta biblioteca / tecnologia pela comunidade de desenvolvedores? Quantas estrelas ela tem no GitHub?
- Com que frequência um desenvolvedor responde a um problema?
- Com que frequência o desenvolvedor atualiza a biblioteca?
- Quanto tempo os novos desenvolvedores gastarão aprendendo a tecnologia usada?
- Como a biblioteca afetará o tamanho do aplicativo?
- Como a biblioteca afetará a velocidade do aplicativo?
- Como a biblioteca afetará a velocidade de construção? Isso o ajuda a economizar tempo de desenvolvimento?
- A biblioteca tem vulnerabilidades?
- A biblioteca estará presente em todas as camadas do projeto? Quão crítico é isso?
- Como a biblioteca limita as opções do desenvolvedor (quase sempre limita). Isso é bom ou ruim?
- Serei capaz de escrever uma solução que será aprimorada para meu projeto dentro de um prazo razoável?
É muito interessante ouvir o que mais você pode procurar ao escolher uma biblioteca. Aguardamos seus comentários, feedback e perguntas!