Estou lendo sobre o desempenho do código e os parâmetros de ajuste há muito tempo. Na verdade, os programas Android são um dos meus focos.
Vamos apresentar primeiro os conceitos básicos ou mais importantes nos quais nos ajudam a alcançar uma solução.
Como o desenvolvedor do Android declarou
O módulo pode ser construído, testado e depurado independentemente
Portanto, os módulos têm seu próprio Gradle & Dependencies . E você pode explorá-lo no projeto Hierarchy Viewer.
De fato, a ênfase da modularização em manutenção é importante. Ao contrário do Performance Matters, a modularização tem esse impacto importante:
- Aumentar a profundidade da herança
Aqui está um diagrama que eu plotei para deixar claro. Como você pode ver, ao usar o módulo discreto, para invocar o Método A, ele é 2N micro secscomparado com o N micro secsmódulo discreto.
Esta questão me veio à sua mente que os métodos referenciados contam o que se refere à profundidade da herança?
A resposta é: Embora o uso da modularização aumente os Métodos referenciados, na verdade, ele não afeta o desempenho do aplicativo e o principal problema possível é Profundidade de herança, na qual na maioria dos casos é ignorável .
Eu enfatizo que o aumento de métodos referenciados na modularização é devido a cada módulo Gradle & Dependencies
Como a modularização de aplicativos pode aumentar drasticamente a contagem de métodos referenciados?
Condições em que o analisador de impacto APK é importante Métodos referenciados
Observe também que a redução e a redução do código também podem alterar consideravelmente o conteúdo de um arquivo DEX após a compilação do código-fonte.
Além da declaração oficial acima, quero adicionar outra condição na qual o analisador de impacto APK é:
quanto o desenvolvedor tem experiência em modularização?
a modularização é como uma casa que a arquitetura (desenvolvedor) define onde deve ser a cozinha e onde deve ser o banheiro e onde deve ser o banheiro.
E se a arquitetura decidir combinar WC e cozinha? Sim, isso é um desastre.
Isso pode acontecer durante a modularização se o desenvolvedor não tiver muita experiência.
Respondendo às perguntas do OP, além de informações adicionais
Aqui eu respondo às perguntas mais frequentes nos comentários
Por que Gradle separado seria adicionado à contagem de métodos referenciados? E para dependências separadas, se o resultado final for um APK único, não creio que dependências duplicadas no 'app' e no módulo de recursos sejam adicionadas à contagem de métodos referenciados.
Como os módulos podem ser construídos, testados e depurados, DEVEM ter o seu próprio Gradle & Dependencies.
Enquanto o projeto de vários módulos estiver sendo cumprido, o compilador gera vários .dexarquivos, incluindo:
- um
.dexarquivo para dependências totalmente integradas
- módulos
.dexs
.dexarquivo de dependências é uma integração de todos os módulos gradles
Vejamos como um gradle de módulo afeta a contagem final de Mothods referenciados ?!
existem 2 APK s com o mesmo resultado, mas a diferença na contagem de métodos referenciados.
Ambas são atividades vazias com 1.7kdiferença na Contagem de Métodos Referenciados muito alta, dependendo de sua funcionalidade. A principal diferença está no Gradle de seu módulo, um deles foi configurado para
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
}
Outro configurado para
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.2.0-alpha01'
implementation 'androidx.constraintlayout:constraintlayout:2.0.0-beta4'
}
Embora sejam apenas atividades vazias, uma diferença mínima em Gradle causou 1.7kdiferença nas contagens de métodos referenciados.
E App Gradle é
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
implementation project(path: ':module')
}
A principal preocupação é por que a adição da contagem de métodos referenciados individualmente é diferente da contagem total de métodos referenciados no Apk Analyzer?
Este é apenas o filtro IDE, nada mais. com certeza, se você selecionar apenas um .dexarquivo Contagens de método de referência é igual a SOMA de cada linha Contagens de métodos referenciados, mas se selecionar vários .dexarquivos, verá uma diferença em SUM e na contagem real devido à igualdade nas referências que o Analyzer preferiu filtrá-los.
nas capturas de tela, você selecionou vários .dexarquivos e, em seguida, o Analyzer filtra a igualdade.
em nosso projeto, estamos usando o arquivo dependencies.gradle centralizado, para que não haja chance de versão diferente. Então, você acha que, mesmo que tenhamos o mesmo / exato conjunto de dependências e suas versões nos módulos de recursos, isso aumentará a contagem de métodos referenciados?
Teoricamente, NÃO deve aumentar a contagem de métodos referenciados. MAS , como expliquei, a Experiência do desenvolvedor afeta fortemente o resultado final.
O Team Analyzer deve verificar e corrigir problemas de desempenho antes do lançamento, como
- regras de proguard
- recursos reduzidos e diminuídos
- androidManifest.xml
- configurações gradle
Agora, quero esclarecer como a Experiência do desenvolvedor e a manutenção do código afetam o resultado final. MESMO se o seu APK usar dependências centralizadas
no exemplo acima, eu aumentei a 5.1kcontagem de métodos referenciados, mesmo que eu tivesse dependências centralizadas !!!!!
Como é possível ?
A resposta é: acabei de adicionar um .jararquivo inútil e oculto no libsdiretório do projeto. tão fácil quanto você pode ver, eu afetei o resultado final.
Como você pode ver Desenvolvedor Experiência afeta result.as finais resultado, Praticamente é possível que métodos referenciados contagens de ser aumentado Embora Teoricamente Should NÃO .
E por que não há diferença na contagem de métodos referenciados quando eu compilo apenas o módulo 'app' desativando a compilação paralela? Deveria ter diminuído, pois apenas as dependências do módulo 'app' teriam sido usadas, certo?
compilação não tem nenhuma relação com os métodos referenciados count.it está de acordo com o que o desenvolvedor deseja cumprir.
Conclusão
Eu cobri todas as possibilidades em torno da questão. De fato, pode surgir de diferentes situações e um desenvolvedor, usando essa diretriz, pode corrigir o problema.
- Eu espero que você descubra por que os métodos referenciados foram aumentados e por que, em alguns casos, pode ser drasticamente aumentado.
- Módulos possui seus módulos Gradle & Dependencies e aumento de modularização. portanto, essas referências de método.
- A modularização realmente afeta o desempenho do aplicativo ignorável, mas torna a manutenção do aplicativo muito melhor.
- A experiência do desenvolvedor em modularização também afeta muito o resultado final.
NOTA IMPORTANTE: quase todas as declarações são de minha investigação e pesquisa. de fato, pode haver erros e falhas e será atualizado para adicionar muito mais informações no futuro.
