441 votes

drawables mipmap pour les icônes

Depuis Android 4.3, nous pouvons maintenant faire usage de l' res/mipmap des dossiers pour stocker les "mipmap" des images.

par exemple , google Chrome pour Android stocke ses icônes dans ces dossiers au lieu de plus normal res/drawable des dossiers.

Comment sont ces mappage des images différentes de l'autre familier drawable images?

Je vois que dans mon manifeste, nous utilisons l' @mipmap/ qualificatif, au lieu de @drawable/, ce qui est logique étant donné la ressource de nom de dossier:

<activity
    android:name=".MipmapDemp"
    android:icon="@mipmap/ic_launcher" />

Références:

La Android 4.3 Api document a ceci à dire:

À l'aide d'un mappage comme la source de votre image bitmap ou drawable est un simple de manière à fournir une image de qualité et d'image différentes échelles, ce qui peut être particulièrement utile si vous attendez de votre image pour être mis à l'échelle au cours d'une de l'animation.

Android 4.2 (API level 17) ajout du support pour les mipmaps dans l'image Bitmap classe-Android swaps de la mip images de votre image lorsque vous avez fourni un mappage de la source et qui ont permis de setHasMipMap(). Maintenant dans Android 4.3, vous pouvez activer cette option pour un BitmapDrawable objet, par fournir un mappage de l'actif et du réglage de l'android:mipMap attribut dans une bitmap fichier de ressources ou en appelant hasMipMap().

Je ne vois rien là-dedans qui m'aide à comprendre?


XML Bitmap ressources ont un android:mipMap de la propriété:

Boolean. Active ou désactive le mappage de l'indice. Voir setHasMipMap() pour de plus amples informations. La valeur par défaut est false.

Cela ne s'applique pas à l'écran de lancement des icônes aussi loin que je peux voir.


La question a été soulevée sur des Groupes de Google (le but de La ressource nom "mipmap"?!), à laquelle Romain Guy a répondu:

Il est utile de fournir une image à plus haute résolution qui serait normalement calculée (par exemple, sur une mdpi appareil, le Lanceur peut voulez le plus grand hdpi icône pour afficher un grand raccourcis d'applications.)

J'ai l'impression que cela fait presque un sens, mais pas assez.

Je suis toujours enclin à aller avec Randy Sugianto du suivi:

Quels sont les avantages de cette? Est-il un guide sur la façon d'utiliser mipmaps, probablement pour mieux lanceur d'icônes?


Bien sûr, Wikipédia a une page pour "Mipmap", qui se réfère à une ancienne technique inventé en 1983, que je ne peux pas tout à fait le Android de mise en œuvre.


Doit-on stocker toutes nos icônes d'application en res/mipmap des dossiers de ces jours, et quels sont les lignes directrices pour ces mipmap images?


Mise à jour #1

Voici un blog qui essaie de l'expliquer un peu.

Mais l'image utilisée dans ce blog montre à quoi ressemble 1 fichier avec plusieurs logo. Ce n'est pas ce que je vois dans google Chrome, mipmap dossier.

Google Chrome, mipmap-hdpi le dossier contient 3 images. L'un est le logo google Chrome, sur son propre.

Chrome mipmap-hdpi icon.png

Étrangement, il est 72x72, pas 48x48 qui je m'attends à voir.

C'est peut-être tout cela - nous avons juste besoin de garder plus d'icônes dans le mappage des dossiers?


Mise à jour #2

Les Développeurs Android Blog du 23/10/2014 confirme de nouveau l'idée de l'utilisation de l' mipmap des dossiers pour les icônes de l'application:

Lorsque l'on parle du Nexus 6 densité de l'écran, l'auteur écrit:

Il est recommandé de placer vos icônes d'applications dans mipmap - dossiers (pas le drawable - dossiers), car ils sont utilisés à des résolutions différentes de l'appareil de la densité de courant. Par exemple, un xxxhdpi icône de l'application peut être utilisé sur le lanceur pour un xxhdpi appareil.


257voto

Kevin TeslaCoil Points 4273

Il y a deux distincts utilise de mipmaps.

1) Pour les icônes du lanceur lors de la construction de la densité spécifique Apk. Certains développeurs construisent Apk pour chaque densité, pour garder l'APK de la taille vers le bas. Cependant, certains lanceurs (fourni avec certains appareils, ou disponible sur le Play Store) l'utilisation de plus grandes tailles d'icône de la norme 48dp. Les lanceurs d'utilisation getDrawableForDensity et de l'échelle vers le bas, si nécessaire, plutôt que de l', les icônes sont de haute qualité. Par exemple sur un hdpi tablette le lanceur peut charger le xhdpi icône. En plaçant votre icône de lancement dans le mipmap-xhdpi répertoire, il ne sera pas dépouillé la façon dont un drawable-xhdpi répertoire est lors de la construction d'un APK pour hdpi appareils. Si vous êtes à la construction d'une seule APK pour tous les périphériques, puis ce n'est pas vraiment important que le lanceur peut accéder à la drawable ressources pour la densité désirée.

2) La valeur réelle de mappage de l'API à partir de 4.3. Je n'ai pas l'habitude de cela et ne suis pas familier avec elle. Il n'est pas utilisé par l'Android Open Source Project lanceurs et je ne suis pas au courant de tout autre lanceur de l'aide.

23voto

matiash Points 14851

La Android la mise en œuvre de mipmaps en 4.3 est exactement la technique de 1983 expliqué dans l'article de Wikipedia :)

Chaque image bitmap du mipmap est un double de la réduction des effectifs des principal de la texture, mais à une certaine réduction du niveau de détail. Bien que l' principal de la texture serait toujours être utilisé lorsque la vue est suffisante pour rendre il en détails, le moteur de rendu va basculer dans un mappage d'image (...) lorsque la texture est vue à partir d'une distance ou d'une petite taille.

Bien que ce qui est décrit comme une technique pour les applications graphiques 3D (qu'il mentionne "la consultation à distance"), elle s'applique tout aussi bien à la 2D (traduit comme "tiré est un espace plus petit", c'est à dire "limité").

Pour un béton Android exemple, imaginez que vous avez une Vue avec un certain arrière-plan dessiné (en particulier, un BitmapDrawable). Vous pouvez désormais utiliser une animation à l'échelle de 0,15 de sa taille d'origine. Normalement, cela nécessiterait d'en réduire l'image d'arrière-plan pour chaque image. Cette "extrême" downscaling, cependant, peuvent produire des artefacts visuels.

Vous pouvez, toutefois, fournir une mipmap, ce qui signifie que l'image est déjà pré-rendus de quelques-uns des échelles spécifiques (disons 1.0, 0.5, 0.25). Chaque fois que le film d'animation "traverse" le seuil de 0,5, au lieu de continuer à réduire la taille de l'original, 1.0 taille de l'image, il passera à 0,5 image et à la baisse, ce qui devrait fournir un meilleur résultat. Et ainsi de suite à mesure que l'animation continue.

C'est un peu théorique, car il est fait par le moteur de rendu. Selon la source de la classe Bitmap, c'est juste un indice, et le moteur de rendu peut ou peut ne pas l'honorer.

/**
 * Set a hint for the renderer responsible for drawing this bitmap
 * indicating that it should attempt to use mipmaps when this bitmap
 * is drawn scaled down.
 *
 * If you know that you are going to draw this bitmap at less than
 * 50% of its original size, you may be able to obtain a higher
 * quality by turning this property on.
 * 
 * Note that if the renderer respects this hint it might have to
 * allocate extra memory to hold the mipmap levels for this bitmap.
 *
 * This property is only a suggestion that can be ignored by the
 * renderer. It is not guaranteed to have any effect.
 *
 * @param hasMipMap indicates whether the renderer should attempt
 *                  to use mipmaps
 *
 * @see #hasMipMap()
 */
public final void setHasMipMap(boolean hasMipMap) {
    nativeSetHasMipMap(mNativeBitmap, hasMipMap);
}

Je ne suis pas tout à fait sûr de savoir pourquoi cela serait particulièrement adapté pour les icônes de l'application. Bien que Android sur les tablettes, ainsi que certains lanceurs (par exemple, GEL), demande une icône "une densité plus élevée" pour l'afficher en plus grand, de ce qui est censé être fait en utilisant le mécanisme régulier (c - drawable-xxxhdpi, &c).

-1voto

Juan Points 183

La compréhension que j'ai sur les mipmap est plus ou moins comme ceci:

Lorsqu'une image doit être établi, étant donné que nous avons différentes tailles d'écran sont résolutions, certains d'échelle aurez à prendre partie.

Si vous avez une image qui est ok pour un bas de gamme de téléphone cellulaire, lors de la mise à l'échelle à la taille d'une tablette 10" il faut "inventer" des pixels qui n'existe pas réellement. C'est fait avec certains algorithme d'interpolation. Plus la quantité de pixels qui doivent être inventé, le plus de temps prend le processus et la qualité commence à échouer. La meilleure qualité est obtenue grâce à des algorithmes plus complexes qui prennent plus de temps (en moyenne autour de pixles vs copier le pixel le plus proche par exemple).

Afin de réduire le nombre de pixels qui doivent être inventé, avec mipmap vous fournir différentes tailles/rsolutions de la même image, et le système va choisir la plus proche de l'image à la résolution qui doit être affiché et faire la mise à l'échelle à partir de là. Cela devrait réduire le nombre de inventée pixels de l'économie des ressources à utiliser dans le calcul de ces pixels pour fournir une image de bonne qualité.

J'ai lu à ce sujet dans un article expliquant un problème de performance dans libgdx lors du redimensionnement des images:

http://www.badlogicgames.com/wordpress/?p=1403

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X