Entendendo a Idependência de Dencidade do Android

Android é um sistema operacional móvel com poucas limitações no hardware de seus aparelhos. Os fabricantes podem criar dispositivos de quase qualquer forma de tela, o tamanho e densidade. Os dispositivos podem ter teclados e botões físicos, ou apenas teclados e botões virtuais. Embora essa flexibilidade é grande para permitir personalização dispositivo, cria-se alguns obstáculos para desenvolvedores de aplicativos. Em primeiro lugar, como pode aplicativos suportam todas essas várias configurações de dispositivos com uma experiência consistente? Além disso, como os aplicativos podem tirar proveito de dispositivos que possuem hardware final maior ou mais recursos do que os outros? Android foi construído com isso em mente, e dá ferramentas de desenvolvimento para apoiar todas as configurações de dispositivo e otimizar a experiência para outras configurações do dispositivo, que será abordado mais tarde.Para que um aplicativo seja flexível e compatível com qualquer configuração do dispositivo, o pensamento cuidadoso é necessário para garantir que a experiência do usuário é apropriado em configurações. Ao criar um aplicativo Android, designers e desenvolvedores devem criar interfaces do usuário que funcionam bem com o pequeno espaço de um telefone, eo grande espaço de um tablet. Eles também devem levar em conta com recursos de imagem otimizada para telas de alta e baixa densidade. Embora existam muitas maneiras de criar interfaces otimizadas para diferentes tamanhos de tela e orientações, o foco deste blog é a forma como o Android suporta diferentes densidades de tela.O conceito básico do Android é ter interfaces de utilizador que têm elementos que são aproximadamente do mesmo tamanho físico, independentemente da densidade da tela. Por quê? Simples, o dedo de um usuário é o mesmo tamanho físico, não importa o que a densidade da tela é. Um botão ou item clicável deve processar aproximadamente o mesmo tamanho físico (maior do que a ponta do dedo) em qualquer dispositivo. Isto também vale para texto, palavras deve processar aproximadamente o mesmo tamanho da fonte (legível) através de dispositivos.Densidade tela, e não resoluçãoTela de densidade é uma relação de exibição de tamanho e resolução, que pode ser quantificada como pontos por polegada, ou dpi. Quanto maior o dpi, menor é cada pixel individualmente e maior clareza. Simplificando, um dpi maior significa mais detalhe é exibida por polegada, mas não necessariamente se correlacionam com uma resolução de tela superior. Por exemplo, o Nexus Galaxy (4,65 "diagonal) tem uma resolução de 720x1280 px, enquanto o Nexus 7 (7" diagonal) tem uma resolução de 800x1280 px. É um equívoco comum supor que eles têm sobre a mesma densidade da tela, uma vez que suas resoluções são quase idênticos. No entanto, o Galaxy Nexus tem uma densidade de tela de cerca de 316 dpi eo Nexus 7 tem uma densidade de tela de 216 dpi, não chega nem perto. Isto porque, enquanto eles estão exibindo a mesma resolução, eles também são exibi-lo em diferentes quantidades de espaço. Novamente, a densidade da tela é uma proporção de tamanho e resolução de exibição, e ambos os factores que contribuem para a densidade.Baldes de densidadeHá uma infinidade de dispositivos Android com diferentes densidades de tela, que pode variar de 100 dpi para mais de 480 dpi. A fim de otimizar imagens para todas estas densidades de tela, as imagens precisam ser criados em diferentes resoluções. No entanto, tentando otimizar todos os recursos de imagem para cada densidade possível seria incrivelmente entediante, causar tamanhos app para ser enorme, e simplesmente não é uma solução viável. Como compromisso, o Android usa densidade "baldes" que são usados ​​para agrupar dispositivos juntos dentro de certos limites de densidade de tela. Dessa forma, os aplicativos são apenas necessárias para otimizar imagens para cada balde de densidade, em vez de cada densidade possível. Isso mantém a carga de trabalho razoável para designers e desenvolvedores, e também evita que o tamanho do aplicativo de balonismo. Evidentemente, existe uma compensação, levando a variação no tamanho físico processado de imagens, dependendo da densidade do dispositivo, que será mostrado mais adiante.Então, como designers e desenvolvedores otimizar recursos de imagem para estes baldes de densidade? Primeiro, o tamanho renderizada da imagem precisa ser decidido. Por exemplo, digamos que um ícone se destina a ser 0.5x0.5 em quando processado em uma tela. Em seguida, a imagem deve ser criada no maior densidade suportado, ou como um gráfico vetorial escalável. A melhor prática é para apoiar a densidade máxima, que atualmente é xxhdpi em 480 dpi. Em 480 dpi, uma 0.5x0.5 na imagem se converte em 240x240 px. Uma vez que a versão máxima densidade do recurso gráfico é criado em 240x240 px, que pode depois ser reduzida proporcionalmente para criar cada versão balde densidade subsequente, cada uma utilizando o mesmo nome de ficheiro. Google não recomenda a criação de uma versão tvdpi em 213 dpi, uma vez que só é necessária para certas aplicações e usado por um pequeno conjunto de dispositivos. Uma vez que todas as versões têm sido criados, eles podem ser adicionados a pastas "drawable", usando identificadores de recurso para dizer que Android densidade balde que se destinam. Por último, basta referenciar o recurso gráfico em layouts XML e de código usando o nome gerado no arquivo "R", que contém referências a todos os recursos do aplicativo. Android irá carregar os recursos em tempo de execução, fazendo seu melhor para corresponder a configuração do dispositivo real para os identificadores de recursos aplicados. Se qualquer versão densidade de um recurso de imagem não está incluído, o Android vai usar uma outra versão densidade e escalá-lo para o tamanho proporcional necessário. Não é recomendado deixar Android fazer isso, pois não é tão eficiente nem tão preciso em manipular recursos como software de edição de imagem.Unidades de DimensãoNo Android, interfaces de usuário podem ser criadas em xml, e programaticamente no código. Para expressar uma forma de distância ou comprimento, há várias unidades para as dimensões. Estes podem ser usados ​​em elementos para definir as larguras, alturas, margens, preenchimento e muito mais.px - Um pixel de real na tela. Esta é uma unidade dependente da densidade, e o tamanho físico de um único "px", que varia em função da densidade da tela.em - Um polegada física na tela. Esta é uma unidade independente da densidade, e o tamanho físico de um único "no" é o mesmo em cada densidade de tela. O número de pixels num único "no" traduz a varia dependendo da densidade da tela.mm - Um milímetro física na tela. Esta é uma unidade independente da densidade, e o tamanho físico de um único "mm" é o mesmo em cada densidade de tela. Existem 25,4 "mm" em uma polegada. O número de pixels num único traduz "mm" a varia dependendo da densidade da tela.pt - Um ponto, uma unidade de tamanho de fonte comum, na tela. Esta é uma unidade independente da densidade, e o tamanho físico de um único "PT" é o mesmo em cada densidade de tela. Há 72 "pt" em uma polegada. O número de pixels num único traduz "PT" varia de acordo com a densidade da tela.dp - Um pixel independente densidade. Esta é uma unidade independente da densidade, no entanto, o tamanho físico de um único "DP" só é aproximadamente o mesmo em cada densidade de tela. Há cerca de 160 "dp" em uma polegada. Um factor de escala, dependendo da densidade do balde do dispositivo, é aplicada para converter "DP" ao número de pixels em 160 dpi. O número de pixels num único traduz "DP" a varia dependendo da densidade de pixel na tela e o balde densidade do dispositivo cai.sp - Um pixel independente escala, especialmente designado para tamanhos de texto. Esta é uma unidade independente da densidade, no entanto, o tamanho físico de um único "sp" só é aproximadamente o mesmo em cada densidade de tela. Factores de escala, dependendo da densidade do balde do dispositivo, bem como de preferência de tamanho de texto do utilizador, são aplicados para converter "sp" ao número de pixels em 160 dpi. O número de pixels, isto resulta de varia dependendo da densidade da tela e o balde densidade do dispositivo cai.A Magia de "dp"Como discutido, "px" não é independente da densidade, e não é a mesma em todos os dispositivos de tamanho, ao passo que "no", "mm", e "PT" são independente da densidade e do mesmo tamanho em cada dispositivo. No entanto, "DP" e "sp" é um pouco diferente do resto, uma vez que são independentes da densidade, mas eles não são do mesmo tamanho em cada dispositivo. Por que isso? A resposta está em como "dp" e "sp" são calculadas em pixels. Android usa MDPI, 160 dpi, como sua densidade de base, onde 1DP é 1px. Essencialmente, "DP" pode ser considerado como "px" a 160 dpi. É por isso que dp 160 converte a cerca de 1 cm Assim, dependendo da relação entre a densidade de um balde de dispositivos e a densidade de linha de base, MDPI, um factor de escala aplicado para converter "DP" para "px".A razão "DP" tende a variar em tamanho físico é devido ao mesmo factor de escala a ser aplicado durante todo o balde densidade. O fator de escala é calculado com a densidade do balde dpi, e não real dpi do dispositivo. Quando dpi do dispositivo não é exatamente o mesmo que a sua densidade dpi de balde, a mesma quantidade de "dp" converte para a mesma quantidade "px". Isto leva a mesma quantidade de "px" a ser exibido em diferentes telas de densidade, que tornam pelo tamanhos diferentes.A tabela acima mostra como 100 dp converte em "px" em diferentes dispositivos de densidade. 100 dp deve cerca de traduzir para 0.625, e faz isso perfeitamente nos tamanhos de balde. No entanto, quando o dpi do dispositivo é menor do que a densidade do dpi balde, os pixels são fisicamente maior, e a mesma quantidade de "DP" se tornar maior, e vice-versa.Então, isso levanta a questão: por que "dp" permitir que esta variação em seu tamanho físico? Basicamente, o Android sacrifica alguma precisão no tamanho físico, de modo a manter o desempenho e qualidade de exibição. Desde "DP" escalas para "px", usando índices balde densidade do Android (0.75:1.0:1.5:2.0:3.0), isso permite minimal "px" arredondamento e cálculos simples. Além disso, uma vez que os factores de escala são proporcionais aos rácios de balde densidade, "dp" tornará proporcionalmente aos recursos de imagem fornecidos para cada densidade. Por último, quando a escala gráfica, o melhor é ficar o mais próximo de números inteiros e frações simples, como frações complexas podem criar artefatos e aliasing.Definindo limites do elemento de interface do usuárioAo definir os atributos width e height em um elemento de interface do usuário, há opções especiais disponíveis, bem como as unidades de dimensão.wrap_content - Isso vai "quebrar" os limites do elemento a ser grande o suficiente para conter o seu conteúdo (imagens, textos, etc), elementos filhos nele contidos, além de estofamento. Essencialmente, este conjunto o elemento de ser do tamanho do seu maior teor de, e não irá ajustar o tamanho do elemento.match_parent (fill_parent depreciado em API 8) - Este será "igualar" os limites do elemento de seu elemento pai, usando o espaço máximo permitido, menos estofamento. Essencialmente, isso permite que o elemento seja o tamanho máximo da sua mãe permite, e ajustar o tamanho do elemento, se necessário.unidade dimensão - Isto irá definir os limites do elemento de precisão o tamanho da unidade de dimensão, cada discutido anteriormente. Essencialmente, este define o elemento de ser do tamanho exacto da unidade de dimensão, e ajustar o tamanho do elemento, se necessário.Programa demonstrativoPara demonstrar como tudo isso vem junto, criar e testar um exemplo de aplicação é necessária. Para este exemplo, ter um projeto que usa uma imagem 200x200 px em xhdpi, ou 320 dpi. Para simplificar, o recurso de imagem pode ser denominada "android_logo". Usando o px de resolução de 200x200 a 320 ppp como o tamanho físico desejado, os seus tamanhos alternados pode ser calculado.Imagem 200x200px em xhdpi (320dpi)Depois de calcular as dimensões específicas da imagem densidade requeridas, podem ser criados por dimensionamento para baixo a partir da versão de densidade máxima, tal como explicado anteriormente. Em seguida, cada versão densidade da imagem pode ser colocado no seu respectivo filtro "estirável" usando identificadores de recursos. Android vai então escolher o melhor recurso em tempo de execução, de acordo com a configuração do dispositivo.As pastas de recursos utilizando identificadoresAgora, para expor as possíveis maneiras de manter a independência densidade, a imagem deve ser definido para o mesmo tamanho físico, utilizando cada uma das unidades de medida independentes de densidade. Uma vez que "px" não é independente da densidade, e "sp" é concebido para o texto, que pode ser omitida.Exemplo de dispositivo: xhdpi BucketAo utilizar um esquema com a mesma imagem usando cada unidade dimensão definida para o mesmo tamanho físico, é possível comparar a dimensão de cada unidade funciona. Ao executar em um emulador de 320 dpi, as imagens mostram exatamente no mesmo tamanho, para cada unidade de dimensão. Isto é esperado uma vez que o dpi do emulador corresponde exatamente ao balde densidade xhdpi, 320 dpi. No entanto, quando executado num Galaxy Nexus, a qual também cai dentro da densidade balde xhdpi, existem algumas variações no tamanho da imagem.320dpi Emulator TelaGalaxy Nexus TelaApós a inspeção, é evidente que as imagens definidas com "wrap_content" eo jogo "dp" em tamanho, enquanto as imagens definidas com "in", "mm", e "pt", também do mesmo tamanho. No entanto, os dois grupos ou imagens não coincidem entre si. Então, o que está acontecendo aqui? Como discutido anteriormente, "wrap_content" e "DP" use os rácios balde densidade para converter correctamente as suas dimensões. Assim, a imagem de 200x200 px calcula sobre o dispositivo. No entanto, a densidade de tela real do Galaxy Nexus não é exatamente 320 dpi, tem um xdpi 315,3 e 318,7 Ydpi. Uma vez que a densidade real é menor do que a densidade xhdpi balde de 320 dpi, os pixels do dispositivo real será maior do que o tamanho físico pretendido de 0,625 polAo analisar as imagens definidas com "in", "mm", e "pt", observe que cada imagem se converte em 197.1x199.2 px. Como discutido anteriormente, "em", "mm", e "pt" todos usam a densidade do dispositivo real para converter as suas dimensões de pixels. Uma vez que a densidade real do Galaxy Nexus é inferior à densidade balde xhdpi em 320 dpi, menos pixels são necessários para cobrir 0.625x0.625, e a imagem fica reduzida.Ao comparar as imagens renderizadas, é evidente que as imagens definidas com "wrap_content" e "dp" têm tamanhos físicas menos precisas, mas a qualidade da imagem é melhor do que as imagens definidas com "in", "mm", e "pt" .Sem escala com "wrap_content" e "DP" (esquerda). Escalando com "in", "pt" e "mm" (direita).Exemplo de dispositivo: hdpi BucketEm seguida, quando executado em um emulador de 240 dpi, as imagens são exibidas no momento exato o mesmo tamanho, para cada unidade de dimensão. Novamente, isso é esperado uma vez que o dpi do emulador corresponde exatamente ao balde densidade hdpi em 240 dpi. Mas, como antes, quando executado num dispositivo hdpi, desta vez um robô genial, existem algumas variações no tamanho da imagem.240dpi Emulator TelaDroid Incredible TelaSemelhante ao anterior, o Droid Incredible exibe o "wrap_content" e as imagens "DP" em 150x150 px. Como a densidade real do Droid Incredible é de 254x254 dpi, maior do que o balde hdpi a 240 dpi, isso significa que os pixels em sua tela é menor que o tamanho da caçamba. Isso faz com que a imagem 150x150 px para parecer menor do que o tamanho da linha de base de 0,625 polegadas As imagens definidas com "in", "mm", e exibição "pt" no 158.8x158.8 px pois são necessários mais pixels para cobrir 0.625x0. 625, e a imagem fica ampliados.Assim como no Galaxy Nexus, o "wrap_content" e imagens "DP" render com dimensionamento menos precisos, mas a melhor qualidade de imagem.Sem escala com "wrap_content" e "DP" (esquerda). Escalando com "in", "pt" e "mm" (direita).A fonte completo desta demo pode ser encontrado no GitHub, e também está anexado abaixo.Unidade de Melhores Práticas dimensãopx - Não manter a independência densidade. Nunca deve ser necessário.em / mm / pt - Mantém independência densidade, mas calcula a quantidade exata de pixels que podem prejudicar o desempenho e causar artefatos de imagem e aliasing. Necessário se dimensionamento preciso é necessário, e qualquer desvio é inaceitável. Também é útil para definir as distâncias entre os elementos, quando as distâncias exatas são necessários.dp - Mantém independência densidade e melhor qualidade de imagem, mas à custa de pequenos desvios no tamanho físico. Desde que calcula usando a escala balde densidade, proporciona dimensionamento proporcionalmente precisa com recursos de imagem. Esta é a unidade de dimensão recomendada de usar para definir limites sobre os elementos ou as distâncias entre elas.sp - Mantém independência da densidade e da qualidade da fonte, mas a custo de pequenos desvios em tamanho físico. Esta é a unidade de dimensão recomendada para usar para o dimensionamento da fonte só, já que tem densidade e tamanho preferência de texto do usuário em conta.ResumoPara recapitular, as chaves para manter a independência densidade:

    Decida o tamanho processado física necessária necessário para cada ativo de imagem.
    Design gráfico ativos imagem do vetor, ou ativos de imagem em bruto maior do que o tamanho necessário para o balde de densidade máxima.
    Criar versões específicas de densidade de cada ativo de imagem para cada balde de densidade, e colocá-los na pasta de recurso próprio "drawable" usando identificadores.
    Ao definir limites para as imagens, use "wrap_content" para melhor visualização ", match_parent" para preencher a tela, ou "dp" para um tamanho fixo.
    Ao definir distâncias em layouts, use "dp" para melhor visualização. Só use "in", "mm" ou "pt" se um tamanho preciso é necessário. Nunca deve haver um uso para "px".Com o entendimento de como Android lida com a exibição de interfaces de usuário em diferentes telas de densidade, torna-se muito mais fácil para projetar e desenvolver aplicativos otimizados para qualquer exibição de densidade.

Original: http://blogs.captechconsulting.com/blog/steven-byle/understanding-
density-independence-android