Drawable mipmap per icone

Da Android 4.3 (Jelly Bean) ora possiamo utilizzare le res/mipmapcartelle per archiviare immagini "mipmap".

Ad esempio, Chrome per Android memorizza le sue icone in queste cartelle anziché nelle cartelle più normali res/drawable.

In che modo queste immagini mipmap sono diverse dalle altre immagini disegnabili familiari?

Vedo che nel mio manifest, usiamo il @mipmap/qualificatore, invece di @drawable/, che ha senso dato il nome della cartella delle risorse:

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

Riferimenti:

Il documento API 4.3 di Android ha il seguente da dire:

L'uso di una mipmap come sorgente della bitmap o del disegno è un modo semplice per fornire un'immagine di qualità e varie scale di immagini, che può essere particolarmente utile se si prevede che l'immagine venga ridimensionata durante un'animazione.

Android 4.2 (livello API 17) ha aggiunto il supporto per le mipmap nella classe Bitmap: Android scambia le immagini mip nella tua Bitmap quando hai fornito una fonte mipmap e hai abilitato setHasMipMap (). Ora in Android 4.3, puoi abilitare le mipmap anche per un oggetto BitmapDrawable, fornendo un asset mipmap e impostando l'attributo android: mipMap in un file di risorse bitmap o chiamando hasMipMap ().

Non vedo niente lì dentro che mi aiuti a capire.

Le risorse Bitmap XML hanno una android:mipMapproprietà:

Booleano. Abilita o disabilita il suggerimento mipmap. Vedere setHasMipMap () per ulteriori informazioni. Il valore predefinito è falso.

Questo non si applica alle icone di avvio per quanto posso vedere.

La domanda è stata sollevata su Google Gruppi ( lo scopo del nome della risorsa "mipmap" ?! ), a cui Romain Guy ha risposto:

È utile fornire un'immagine con una risoluzione maggiore che verrebbe normalmente calcolata (ad esempio, su un dispositivo mdpi, Launcher potrebbe voler visualizzare l'icona di HDPI più grande per visualizzare scorciatoie di app di grandi dimensioni).

Sento che questo ha quasi senso, ma non del tutto.

Sono ancora propenso a seguire il seguito di Randy Sugianto:

Quali sono i vantaggi di questo? C'è qualche guida su come usare le mipmap, probabilmente per le migliori icone di avvio?

Naturalmente, Wikipedia ha una pagina per "Mipmap" , che si riferisce a una tecnica più antica inventata nel 1983, che non riesco a mettere in relazione con l'attuale implementazione di Android.

Oggi dovremmo archiviare tutte le icone delleres/mipmap nostre app in cartelle e quali sono le linee guida per queste immagini mipmap?

Aggiornamento n. 1

Ecco un post sul blog che prova a spiegarlo un po '.

• Mipmapping per drawable in Android 4.3

Ma l'immagine usata in quel post sul blog mostra quello che sembra un file con molti loghi. Questo non è quello che vedo nella cartella mipmap di Chrome.

La mipmap-hdpicartella di Chrome contiene tre immagini. Uno è il logo Chrome, da solo.

Stranamente, è 72x72, non 48x48 che mi aspetterei di vedere.

Forse è tutto ciò che c'è da fare: dobbiamo solo mantenere icone più grandi nelle cartelle mipmap?

Aggiornamento n. 2

Il post sul blog degli sviluppatori Android del 23/10/2014 conferma ancora l'idea di utilizzare le mipmapcartelle per le icone delle applicazioni:

• Preparare le tue app per Nexus 6 e Nexus 9

Quando parla della densità dello schermo del Nexus 6, l'autore scrive:

È consigliabile posizionare le icone delle tue app in cartelle mipmap (non cartelle disegnabili) perché vengono utilizzate a risoluzioni diverse dalla densità corrente del dispositivo. Ad esempio, un'icona dell'app xxxhdpi può essere utilizzata nel programma di avvio per un dispositivo xxhdpi.

Aggiornamento n. 3

Nota che Android Studio crea le ic_launcher.pngicone nelle mipmap...cartelle anziché nelle drawable...cartelle in cui Eclipse ha usato per crearle.

Esistono due usi distinti delle mipmap:

1. Per le icone di avvio durante la creazione di APK specifici per la densità. Alcuni sviluppatori creano APK separati per ogni densità, per mantenere basse le dimensioni dell'APK. Tuttavia, alcuni lanciatori (forniti con alcuni dispositivi o disponibili sul Play Store) utilizzano dimensioni dell'icona più grandi rispetto allo standard 48dp. I launcher usano getDrawableForDensity e riducono se necessario, anziché verso l'alto, quindi le icone sono di alta qualità. Ad esempio, su un tablet HDPI, il programma di avvio potrebbe caricare l'icona xhdpi. Posizionando l'icona di avvio nella directory mipmap-xhdpi, non verrà rimossa come una directory drawable-xhdpi quando si crea un APK per dispositivi hdpi. Se stai creando un singolo APK per tutti i dispositivi, questo non ha molta importanza in quanto il programma di avvio può accedere alle risorse disegnabili per la densità desiderata.

2. L'API mipmap effettiva da 4.3. Non l'ho usato e non ne ho familiarità. Non viene utilizzato dai launcher del progetto Open Source Android e non sono a conoscenza di altri launcher che utilizzano.

Sembra che Google abbia aggiornato i propri documenti da tutte queste risposte, quindi spero che questo possa aiutare qualcun altro in futuro :) Mi sono appena imbattuto in questa domanda, mentre creavo un nuovo (nuovo nuovo) progetto.

TL; DR: i disegni estraibili possono essere eliminati come parte dell'ottimizzazione delle risorse specifiche di dp. Le mipmap non verranno rimosse.

Diverse app di avvio della schermata iniziale su dispositivi diversi mostrano le icone di avvio delle app a varie risoluzioni. Quando le tecniche di ottimizzazione delle risorse dell'app rimuovono le risorse per le densità dello schermo non utilizzate, le icone di avvio possono sembrare sfocate perché l'app di avvio deve ingrandire un'icona a risoluzione inferiore per la visualizzazione. Per evitare questi problemi di visualizzazione, le app devono utilizzare le mipmap/cartelle delle risorse per le icone di avvio. Il sistema Android conserva queste risorse indipendentemente dalla riduzione della densità e garantisce che le app di avvio possano scegliere le icone con la migliore risoluzione per la visualizzazione.

(da http://developer.android.com/tools/projects/index.html#mipmap )

In che modo queste immagini mipmap sono diverse dalle altre immagini disegnabili familiari?

Ecco i miei due centesimi nel cercare di spiegare la differenza. Esistono due casi da affrontare quando si lavora con le immagini in Android:

1. Vuoi caricare un'immagine per la densità del tuo dispositivo e la utilizzerai "così com'è", senza modificarne le dimensioni effettive . In questo caso dovresti lavorare con drawable e Android ti darà l'immagine più adatta.

2. Vuoi caricare un'immagine per la densità del tuo dispositivo, ma questa immagine verrà ingrandita o ridotta . Ad esempio, questo è necessario quando vuoi mostrare un'icona di avvio più grande o hai un'animazione, che aumenta le dimensioni dell'immagine. In tali casi, per garantire la migliore qualità dell'immagine, è necessario inserire l'immagine nella cartella mipmap . Ciò che Android farà è, proverà a raccogliere l'immagine da un bucket a densità più elevata invece di ridimensionarla. Ciò aumenterà la nitidezza (qualità) dell'immagine.

Pertanto, la regola empirica per decidere dove inserire l'immagine sarebbe:

• Le icone di avvio vanno sempre nella cartella mipmap .
• Le immagini, che spesso sono ingrandite (o estremamente ridotte) e la cui qualità è fondamentale per l'app, vanno anche nella cartella mipmap .
• Tutte le altre immagini sono normali drawable .

L'implementazione Android delle mipmap in 4.3 è esattamente la tecnica del 1983 spiegata nell'articolo di Wikipedia :)

Ogni immagine bitmap dell'insieme mipmap è un duplicato ridimensionato della trama principale, ma a un certo livello di dettaglio ridotto. Sebbene la trama principale venga comunque utilizzata quando la vista è sufficiente per renderla in dettaglio, il renderer passerà a un'immagine mipmap adatta (...) quando la trama viene visualizzata a distanza o di dimensioni ridotte.

Sebbene sia descritto come una tecnica per la grafica 3D (in quanto menziona "visualizzazione da una distanza"), si applica anche al 2D (tradotto come "disegnato è uno spazio più piccolo", cioè "ridimensionato").

Per un esempio concreto di Android, immagina di avere una vista con un certo disegno di sfondo (in particolare, a BitmapDrawable). Ora usi un'animazione per ridimensionarla a 0,15 della sua dimensione originale. Normalmente, ciò richiederebbe il ridimensionamento della bitmap di sfondo per ciascun fotogramma. Questo downscaling "estremo", tuttavia, può produrre artefatti visivi.

Puoi, tuttavia, fornire una mipmap, il che significa che l'immagine è già pre-renderizzata per alcune scale specifiche (diciamo 1.0, 0.5 e 0.25). Ogni volta che l'animazione "supera" la soglia di 0,5, invece di continuare a ridimensionare l'immagine originale di 1,0 dimensioni, passerà all'immagine di 0,5 e la ridimensionerà, il che dovrebbe fornire un risultato migliore. E così via mentre l'animazione continua.

Questo è un po 'teorico, dal momento che è effettivamente fatto dal renderer. Secondo l'origine della classe Bitmap, è solo un suggerimento e il renderer può o meno onorarlo.

/**
 * 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);
}

Non sono del tutto sicuro del motivo per cui questo sarebbe particolarmente adatto per le icone delle applicazioni. Sebbene Android su tablet, oltre ad alcuni lanciatori (ad esempio GEL), richieda un'icona "una densità superiore" per mostrarlo più grande, si suppone che ciò avvenga utilizzando il meccanismo normale (cioè drawable-xxxhdpi, ecc.).

Una cosa che ho citato in un altro thread che vale la pena sottolineare: se stai creando versioni diverse della tua app per densità diverse, dovresti conoscere la directory delle risorse "mipmap". Questo è esattamente come risorse "disegnabili", tranne per il fatto che non partecipa alla riduzione della densità quando si creano i diversi target apk.

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

Dal momento che stavo cercando una risposta chiara a questo per determinare il tipo giusto per le icone di notifica, vorrei aggiungere questa chiara dichiarazione all'argomento. È da http://developer.android.com/tools/help/image-asset-studio.html#saving

Nota: i file delle icone di avvio risiedono in una posizione diversa da quella delle altre icone. Si trovano nella cartella mipmap /. Tutti gli altri file di icone si trovano nella cartella drawable / del progetto.

Quando si creano apk separati per densità diverse, vengono rimosse le cartelle disegnabili per altre densità. Questo renderà le icone sfocate nei dispositivi che usano icone di avvio di densità maggiore. Poiché le cartelle mipmap non vengono rimosse, è sempre meglio usarle per includere le icone di avvio.

Esistono due casi da affrontare quando si lavora con le immagini in Android:

1. Vuoi caricare un'immagine per la densità del tuo dispositivo e la utilizzerai "così com'è", senza modificarne le dimensioni effettive. In questo caso dovresti lavorare con drawable e Android ti darà l'immagine più adatta.
2. Vuoi caricare un'immagine per la densità del tuo dispositivo, ma questa immagine verrà ingrandita o ridotta. Ad esempio, questo è necessario quando vuoi mostrare un'icona di avvio più grande, o hai un'animazione, che aumenta le dimensioni dell'immagine. In tali casi, per garantire la migliore qualità dell'immagine, è necessario inserire l'immagine nella cartella mipmap. Ciò che Android farà è, proverà a raccogliere l'immagine da un bucket a maggiore densità invece di ridimensionarla.

COSÌ

Pertanto, la regola empirica per decidere dove inserire l'immagine sarebbe:

1. Le icone di avvio vanno sempre nella cartella mipmap.

2. Le immagini, che spesso sono ingrandite (o estremamente ridotte) e la cui qualità è fondamentale per l'app, vanno anche nella cartella mipmap.

3. Tutte le altre immagini sono normali drawable.

Citazione da questo articolo.

res/
mipmap-mdpi/ic_launcher.png (48x48 pixels)
mipmap-hdpi/ic_launcher.png (72x72)
mipmap-xhdpi/ic_launcher.png (96x96)
mipmap-xxhdpi/ic_launcher.png (144x144)
mipmap-xxxhdpi/ic_launcher.png (192x192)

MipMap per icona app per launcher

http://android-developers.blogspot.co.uk/2014/10/getting-your-apps-ready-for-nexus-6-and.html

https://androidbycode.wordpress.com/2015/02/14/goodbye-launcher-drawables-hello-mipmaps/

Se crei un APK per una risoluzione dello schermo di destinazione come HDPI, lo strumento di pacchetto di risorse Android, AAPT, può eliminare i disegni estraibili per altre risoluzioni non necessarie, ma se si trova nella cartella mipmap, queste risorse rimarranno nella APK, indipendentemente dalla risoluzione di destinazione.

La comprensione che ho di mipmap è più o meno così:

Quando un'immagine deve essere disegnata, dato che abbiamo diverse dimensioni dello schermo sono risoluzioni, alcuni ridimensionamenti dovranno prendere parte.

Se hai un'immagine adatta a un telefono cellulare di fascia bassa, quando la ridimensioni alla dimensione di un tablet da 10 "devi" inventare "pixel che in realtà non esistono. Questo viene fatto con un algoritmo di interpolazione. più quantità di pixel che devono essere inventati, più tempo impiega il processo e la qualità inizia a fallire. La migliore qualità si ottiene con algoritmi più complessi che impiegano più tempo (ad esempio la media dei pixel circostanti rispetto alla copia del pixel più vicino).

Per ridurre il numero di pixel che devono essere inventati, con mipmap fornisci dimensioni / risoluzioni diverse della stessa immagine e il sistema sceglierà l'immagine più vicina alla risoluzione che deve essere renderizzata e farà il ridimensionamento da lì. Ciò dovrebbe ridurre il numero di pixel inventati risparmiando risorse da utilizzare nel calcolo di questi pixel per fornire un'immagine di buona qualità.

Ho letto su questo in un articolo che spiega un problema di prestazioni in libgdx durante il ridimensionamento delle immagini:

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