Os diferentes métodos são indicações de prioridade. Como você os listou, eles vão do menos para o mais importante. Eu acho que como você os mapeia especificamente para logs de depuração no seu código depende do componente ou aplicativo no qual você está trabalhando, bem como como o Android os trata em diferentes tipos de compilação (eng, userdebug e user). Eu trabalhei bastante nos daemons nativos no Android, e é assim que faço. Pode não se aplicar diretamente ao seu aplicativo, mas pode haver algum ponto em comum. Se minha explicação parece vaga, é porque parte disso é mais uma arte do que uma ciência. Minha regra básica é ser o mais eficiente possível, garantir que você possa depurar razoavelmente seu componente sem prejudicar o desempenho do sistema e sempre verificar erros e registrá-los.
V - Impressões de estado em diferentes intervalos ou em eventos que meu componente processe. Também, possivelmente, impressões muito detalhadas das cargas úteis de mensagens / eventos que meu componente recebe ou envia.
D - Detalhes de eventos secundários que ocorrem dentro do meu componente, bem como cargas úteis de mensagens / eventos que meu componente recebe ou envia.
I - O cabeçalho de todas as mensagens / eventos que meu componente recebe ou envia, bem como quaisquer partes importantes da carga útil que são críticas para a operação do meu componente.
W - Tudo o que acontece é incomum ou suspeito, mas não necessariamente um erro.
E - Erros, significando coisas que não deveriam acontecer quando as coisas estão funcionando como deveriam.
O maior erro que vejo as pessoas cometem é que elas usam demais coisas como V, D e eu, mas nunca usam W ou E. Se um erro é, por definição, não deveria acontecer, ou deveria acontecer muito raramente, então é extremamente barato registrar uma mensagem quando ela ocorrer. Por outro lado, se toda vez que alguém pressiona uma tecla você faz um Log.i (), você está abusando do recurso de log compartilhado. Obviamente, use o bom senso e tenha cuidado com os logs de erros para coisas fora do seu controle (como erros de rede) ou aqueles contidos em loops apertados.
Talvez Ruim
Log.i("I am here");
Boa
Log.e("I shouldn't be here");
Com tudo isso em mente, quanto mais próximo o código estiver da "produção pronta", mais você poderá restringir o nível de log de base do seu código (você precisará de V em alfa, D em beta, I em produção ou possivelmente até W em produção ) Você deve executar alguns casos de uso simples e visualizar os logs para garantir que você ainda possa entender principalmente o que está acontecendo ao aplicar uma filtragem mais restritiva. Se você executar o filtro abaixo, ainda poderá saber o que seu aplicativo está fazendo, mas talvez não obtenha todos os detalhes.
logcat -v threadtime MyApp:I *:S
Verbose
registro. É o que você usa quando deseja gerar todas as operações lógicas possíveis.