Dessinables Mipmap pour les icônes

Question

Depuis Android 4.3 (Jelly Bean), nous pouvons désormais utiliser la fonction res/mipmap des dossiers pour stocker les images "mipmap".

Par exemple, Chrome pour Android stocke ses icônes dans ces dossiers au lieu des dossiers habituels. res/drawable les dossiers.

En quoi ces images mipmap sont-elles différentes des autres images dessinables familières ?

Je vois que dans mon manifeste, on utilise le @mipmap/ au lieu du qualificatif @drawable/ ce qui est logique compte tenu du nom du dossier de ressources :

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

---

Références :

El API d'Android 4.3 a déclaré ce qui suit :

L'utilisation d'un mipmap comme source de votre bitmap ou de votre drawable est une manière simple de fournir une image de qualité et diverses échelles d'image, ce qui peut être particulièrement utile si vous prévoyez que votre image sera mise à l'échelle au cours d'une animation.

Android 4.2 (niveau 17 de l'API) a ajouté le support des mipmaps dans la classe Bitmap Android échange les images mip dans votre Bitmap lorsque vous avez fourni une source mipmap et que vous avez activé setHasMipMap(). Maintenant, dans Android 4.3, vous pouvez également activer les mipmaps pour un objet BitmapDrawable, en fournissant une ressource mipmap et en définissant l'attribut Android:mipMap dans un fichier de ressources bitmap ou en appelant hasMipMap().

Je n'y vois rien qui m'aide à comprendre.

---

Ressources XML Bitmap ont un android:mipMap propriété :

Booléen. Active ou désactive l'indice mipmap. Voir setHasMipMap() pour plus d'informations. plus d'informations. La valeur par défaut est false.

Pour autant que je sache, cela ne s'applique pas aux icônes du lanceur.

---

La question a été soulevée sur Google Groups ( A quoi sert le nom de ressource "mipmap" ? ! ), ce à quoi Romain Guy a répondu :

Il est utile de fournir une image à une résolution supérieure à celle qui serait qui serait normalement calculée (par exemple, sur un périphérique mdpi, Launcher pourrait vouloir l'icône hdpi plus grande pour afficher des raccourcis d'applications de grande taille).

J'ai l'impression que ça donne presque un sens à tout ça, mais pas tout à fait.

Je suis toujours enclin à aller avec le suivi de Randy Sugianto :

Quels en sont les avantages ? Existe-t-il un guide sur la façon d'utiliser mipmaps, probablement pour de meilleures icônes de lanceur ?

---

Bien sûr, Wikipédia a une page pour "Mipmap". qui fait référence à une technique plus ancienne inventée en 1983, que je n'arrive pas à relier à l'implémentation actuelle d'Android.

---

Devrions-nous stocker tous nos icônes d'application dans res/mipmap dossiers de nos jours, et quelles sont les directives pour ces images mipmap ?

---

Mise à jour n° 1

Voici un article de blog qui tente de l'expliquer un peu.

• Mipmapping pour les drawables dans Android 4.3

Mais l'image utilisée dans cet article de blog montre ce qui ressemble à un fichier contenant plusieurs logos. Ce n'est pas ce que je vois dans le dossier mipmap de Chrome.

Chrome's mipmap-hdpi contient trois images. L'une est le logo de Chrome, seul.

Étrangement, elle est de 72x72, et non de 48x48 comme je m'y attendais.

Peut-être que c'est tout ce qu'il y a à faire - nous devons juste garder des icônes plus grandes dans les dossiers mipmap ?

---

Mise à jour n°2

L'article du blog des développeurs Android du 23/10/2014 confirme à nouveau l'idée d'utiliser le mipmap pour les icônes des applications :

• Préparer vos applications pour le Nexus 6 et le Nexus 9

En parlant de la densité de l'écran du Nexus 6, l'auteur écrit :

La meilleure pratique consiste à placer les icônes de vos applications dans les dossiers mipmap- (et non dans les dossiers drawable-). dossiers drawable-) car elles sont utilisées à des résolutions différentes de la la densité de courant de l'appareil. Par exemple, une icône d'application en xxxhdpi peut être être utilisée sur le lanceur pour un appareil xxhdpi.

---

Mise à jour n°3

Notez qu'Android Studio crée le ic_launcher.png icônes dans le mipmap... plutôt que les dossiers drawable... dans lesquels Eclipse les a créés.

---

Answer 1

Il existe deux utilisations distinctes des mipmaps :

1. Pour les icônes de lanceur lors de la construction d'APKs spécifiques à la densité. Certains développeurs créent des APK distincts pour chaque densité, afin de réduire la taille de l'APK. Cependant, certains lanceurs (livrés avec certains appareils, ou disponibles sur le Play Store) utilisent des icônes plus grandes que les 48dp standard. Les lanceurs utilisent getDrawableForDensity et réduisent l'échelle si nécessaire, plutôt que de l'augmenter, afin que les icônes soient de haute qualité. Par exemple, sur une tablette hdpi, le lanceur peut charger l'icône xhdpi. En plaçant l'icône de votre lanceur dans le répertoire mipmap-xhdpi, elle ne sera pas dépouillée comme l'est un répertoire drawable-xhdpi lors de la construction d'un APK pour les appareils hdpi. Si vous construisez un seul APK pour tous les appareils, cela n'a pas vraiment d'importance puisque le lanceur peut accéder aux ressources dessinables pour la densité désirée.

2. L'API mipmap actuelle de la version 4.3. Je ne l'ai pas utilisée et ne la connais pas. Elle n'est pas utilisée par les lanceurs du projet Android Open Source et je ne suis pas au courant qu'un autre lanceur l'utilise.

Answer 2

Il semble que Google ait mis à jour leurs docs depuis toutes ces réponses, donc j'espère que cela aidera quelqu'un d'autre à l'avenir :) Je viens de tomber sur cette question moi-même, alors que je créais un nouveau (nouveau nouveau) projet.

TL;DR : les éléments graphiques peuvent être supprimés dans le cadre de l'optimisation des ressources spécifiques à dp. Les mipmaps ne seront pas supprimés.

Différentes applications de lancement de l'écran d'accueil sur différents appareils affichent des icônes de lancement d'applications à différentes résolutions. Lorsque les techniques d'optimisation des ressources des applications suppriment les ressources pour les densités d'écran non utilisées, les icônes de lancement peuvent avoir l'air floues parce que l'application de lancement doit mettre à l'échelle une icône de résolution inférieure pour l'afficher. Pour éviter ces problèmes d'affichage, les applications devraient utiliser l'option mipmap/ les dossiers de ressources pour les icônes du lanceur. Le système Android préserve ces ressources indépendamment de la suppression de la densité, et garantit que les applications de lancement peuvent choisir des icônes avec la meilleure résolution pour l'affichage.

(de http://developer.Android.com/tools/projects/index.html#mipmap )

Answer 3

En quoi ces images mipmap sont-elles différentes des autres images dessinables familières ?

Voici mon point de vue pour tenter d'expliquer la différence. Il existe deux cas de figure lorsque l'on travaille avec des images dans Android :

1. Vous voulez charger une image pour la densité de votre appareil et vous allez l'utiliser "telle quelle", sans changer sa taille réelle . Dans ce cas, vous devez travailler avec Dessinables et Android vous donnera l'image la mieux adaptée.

2. Vous voulez charger une image pour la densité de votre appareil, mais cette image va être augmenté ou diminué . Par exemple, cela est nécessaire lorsque vous souhaitez afficher une icône de lanceur plus grande, ou lorsque vous avez une animation qui augmente la taille de l'image. Dans de tels cas, pour garantir une qualité d'image optimale, vous devez placer votre image dans le fichier mipmap dossier. Ce qu'Android fera, c'est qu'il essaiera de prendre l'image à partir d'un seau de plus haute densité au lieu de la mettre à l'échelle. Cela augmentera la netteté (qualité) de l'image.

Ainsi, la règle empirique pour décider où placer votre image serait :

• Icônes du lanceur vont toujours dans mipmap dossier.
• Les images, qui sont souvent élargi (ou extrêmement réduit) et dont la qualité est critique pour l'application, vont dans mipmap également.
• Toutes les autres images sont habituels Dessinables .

Answer 4

L'implémentation Android des mipmaps en 4.3 est exactement la technique de 1983 expliquée dans l'article Wikipedia :)

Chaque image bitmap de l'ensemble de mipmap est une copie réduite de la texture principale, mais à un certain niveau de détail réduit. Bien que la texture principale soit toujours utilisée lorsque la vue est suffisante pour la rendre dans tous les détails, le moteur de rendu basculera vers une image mipmap appropriée (...) lorsque la texture est vue de loin ou à une petite taille.

Bien que cette technique soit décrite comme étant destinée aux graphiques en 3D (puisqu'il est question de "visionner à distance"), elle s'applique tout aussi bien à la 2D (traduite par "dessiné dans un espace plus petit", c'est-à-dire "réduit").

Pour un exemple concret sous Android, imaginez que vous avez une vue avec un certain arrière-plan à dessiner (en particulier, une BitmapDrawable ). Vous utilisez maintenant une animation pour la réduire à 0,15 de sa taille d'origine. Normalement, il faudrait réduire la taille du bitmap d'arrière-plan pour chaque image. Cette réduction d'échelle "extrême" peut toutefois produire des artefacts visuels.

Vous pouvez toutefois fournir une mipmap, ce qui signifie que l'image est déjà pré-rendu pour quelques échelles spécifiques (disons 1,0, 0,5 et 0,25). Lorsque l'animation "franchit" le seuil de 0,5, au lieu de continuer à réduire l'échelle de l'image originale de taille 1,0, elle passe à l'image de 0,5 et la réduit, ce qui devrait donner un meilleur résultat. Et ainsi de suite, à mesure que l'animation se poursuit.

C'est un peu théorique, puisque c'est en fait le moteur de rendu qui s'en charge. Selon la source de la classe Bitmap, c'est juste une indication, et le moteur de rendu peut l'honorer ou non.

/**
 * 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 vois pas très bien pourquoi cela serait particulièrement adapté aux icônes d'applications, cependant. Bien qu'Android sur les tablettes, ainsi que certains lanceurs (par exemple GEL), demandent une icône "une densité plus haute" pour l'afficher en plus grand, ceci est censé être fait en utilisant le mécanisme habituel (c'est-à-dire drawable-xxxhdpi , &c).

Answer 5

Une chose que j'ai mentionnée dans un autre fil et qui vaut la peine d'être soulignée : si vous construisez différentes versions de votre application pour différentes densités, vous devez connaître le répertoire de ressources "mipmap". C'est exactement comme les ressources "drawable", sauf qu'il ne participe pas à la suppression de la densité lors de la création des différentes cibles apk.

https://plus.google.com/105051985738280261832/posts/QTA9McYan1L