drawable mipmap per le icone

? Richard Le Mesurier @ | Original: StackOverFlow
---

Poiché Android 4.3 ora possiamo utilizzare le res/mipmap cartelle per memorizzare le immagini " mipmap " .

es Chrome per Android memorizza le sue icone di queste cartelle al posto del più normale res/drawable cartelle .

Come sono queste immagini mipmap diversa dalle altre immagini disegnabili familiari ?

Vedo che nel mio manifesto, si usa il qualificatore @mipmap/, invece di @drawable/, che ha un senso dato il nome della cartella di risorsa :

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

Il documento https://developer.android.com/about/versions/android-4.3.html ha il seguente da dire :

Utilizzando un mipmap come sorgente per la bitmap o drawable è una semplice   modo per fornire un'immagine di qualità e diverse scale di immagine, che può essere   particolarmente utile se si prevede la vostra immagine per essere scalata nel corso di una   animazione.

Android ( livello di API 17 ) 4.2 ha aggiunto il supporto per mipmap nel Bitmap   class - Android scambia le immagini MIP nel Bitmap quando hai fornito   una fonte mipmap e hanno permesso setHasMipMap ( ) . Ora in Android 4.3 ,   è possibile abilitare mipmaps per un oggetto BitmapDrawable pure, da   fornendo un bene mipmap e impostando l'androide : mipmap attributo in un   bitmap file di risorse o chiamando hasMipMap ( ) .

Non vedo nulla in là che mi aiuta a capire ?

http://developer.android.com/guide/topics/resources/drawable-resource.html#Bitmap avere una proprietà android:mipMap :

Booleano. Attiva o disattiva il suggerimento mipmap . Vedere setHasMipMap ( ) per   maggiori informazioni . Il valore predefinito è falso .

Questo non si applica ai launcher icone, per quanto posso vedere .

La questione è stata sollevata su Google Gruppi ( https://groups.google.com/forum/#!topic/android-developers/ZUyF0JEwibs ), a cui Romain Guy ha risposto :

È utile fornire un'immagine ad una risoluzione più grande che sarebbe   normalmente calcolato ( ad esempio, su un dispositivo MDPI, avvio potrebbe   volere l'icona hdpi più grande per visualizzare grandi scorciatoie app . )

Mi sento come questo quasi un senso di essa, ma non del tutto .

Sono ancora propenso ad andare con un follow up di Randy Sugianto :

Quali sono i vantaggi di questo ? C'è qualche guida come utilizzare   mipmaps, probabilmente per meglio icone di avvio ?

Naturalmente, http://en.wikipedia.org/wiki/Mipmap, che si riferisce ad una tecnica più vecchia inventata nel 1983, che non riesco a riguardare l' attuale implementazione di Android .

Dovremmo conservare tutte le nostre icone delle applicazioni in res/mipmap Cartelle di questi giorni, e quali sono le linee guida per queste immagini mipmap ?

Update #1

Ecco un post sul blog che cerca di spiegare un po ' .

http://programmium.wordpress.com/2014/03/20/mipmapping-for-drawables-in-android-4-3/

Ma l'immagine utilizzata in questo post del blog mostra quello che appare come 1 file con molte logo in esso . Questo non è quello che vedo nella cartella mipmap di Chrome .

Cartella mipmap-hdpi di Chrome contiene 3 immagini . Uno è il logo Chrome, da solo .

drawable mipmap per le icone

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

Forse è tutto quello che c'è a questo - abbiamo solo bisogno di mantenere le icone più grandi nelle cartelle mipmap ?

Update #2

L' Android Developers Blog post 23/10/2014 conferma ancora una volta l'idea di utilizzare i mipmap cartelle per le icone delle applicazioni :

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

Quando si parla di densità Nexus 6 schermo, l'autore scrive :

E ' buona norma mettere le icone delle applicazioni in cartelle mipmap- ( non il   cartelle drawable- ) perché vengono utilizzati a risoluzioni diverse da   densità di corrente del dispositivo . Ad esempio, l'icona xxxhdpi app può essere   utilizzato nel programma di avvio per un dispositivo xxhdpi .

---

Top 5 Risposta

1Kevin TeslaCoil @

Ci sono due usi distinti di mipmap .

1 ) Per le icone di avvio quando si costruisce APKs specifici di densità . Alcuni sviluppatori costruiscono APKs separati per ogni densità, per mantenere il formato APK giù . Tuttavia alcuni lanciatori ( forniti con alcuni dispositivi, o disponibili sul Play Store ) utilizzano dimensioni delle icone più grandi del 48DP standard. Lanciatori usano getDrawableForDensity e ridimensionare, se necessario, piuttosto che su, in modo che le icone sono di alta qualità . Ad esempio, su un tablet hdpi lanciatore può caricare l'icona xhdpi . Inserendo l'icona di avvio nella directory mipmap - xhdpi, non verrà spogliato il modo in cui una directory disegnabile - xhdpi è quando si costruisce un APK per dispositivi hdpi . Se si sta costruendo un unico APK per tutti i dispositivi, quindi questo non importa come lanciatore può accedere alle risorse disegnabili per la densità desiderata .

2 ) L'API mipmap reale da 4.3 . Non ho usato questo e non sono familiarità con esso . Non è utilizzato dai lanciatori del progetto Android Open Source e io non sono a conoscenza di qualsiasi altro programma di avvio utilizzando .

2Juan @

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

Quando un'immagine ha bisogno di essere disegnato, dato che abbiamo diverse dimensioni dello schermo sono risoluzioni, alcune scala dovrà prendere parte .

Se si dispone di un'immagine che è ok per un telefono cellulare di fascia bassa, quando si scala per le dimensioni di un 10 "tablet bisogna " inventare " i pixel che in realtà non esistono . Ciò viene fatto con un certo algoritmo di interpolazione . Il più quantità di pixel che hanno da inventare, più lungo sarà il processo richiede e la qualità comincia a fallire . la migliore qualità è ottenuta con algoritmi più complessi che richiedono più tempo ( media di pixles circondano vs copiare i pixel più vicino, ad esempio ) .

Per ridurre il numero di pixel che devono inventare, con mipmap fornite diverse dimensioni / rsolutions della stessa immagine, e il sistema sceglierà l'immagine più vicina alla risoluzione che deve essere reso e fare il ridimensionamento da lì . Questo dovrebbe ridurre il numero di pixel inventati risparmio di risorse da utilizzare per il calcolo di questi pixel per fornire un'immagine di buona qualità .

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

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

3matiash @

L'applicazione Android di mipmaps in 4.3 è esattamente la tecnica dal 1983 ha spiegato in questo articolo di Wikipedia :)

Ogni immagine bitmap del set mipmap è un duplicato ridimensionato del   trama principale, ma ad un certo livello ridotto di dettaglio . Sebbene la   trama principale sarebbe ancora essere utilizzato quando la vista è sufficiente a rendere   in tutti i dettagli, il renderer passa ad un'immagine mipmap adatto   ( ... ) Quando la trama è osservato da una distanza o con una dimensione ridotta .

Anche se questo è descritto come una tecnica per la grafica 3D ( come menzionato " visione a distanza " ), si applica altrettanto bene a 2D ( tradotto come " disegnata è uno spazio più piccolo ", cioè " downscaled " ) .

Per un concreto esempio Android, immaginate di avere una visualizzazione con un certo sfondo disegnabile ( in particolare, un BitmapDrawable ) . Ora utilizza un'animazione per scalare a 0,15 della sua dimensione originale . Normalmente, questo richiederebbe downscaling la bitmap di sfondo per ogni fotogramma . Questa downscaling " estremo", tuttavia, può produrre artefatti visivi .

È possibile, tuttavia, fornire un mipmap, il che significa che l'immagine è già pre - rendering per alcune scale specifiche ( diciamo 1.0, 0.5, e 0.25 ) . Ogni volta che l'animazione " attraversa " la soglia di 0,5, invece di continuare a rimpicciolire l'immagine originale, 1.0 di dimensioni, si passa all'immagine 0,5 e downscaling di esso, che dovrebbe fornire un risultato migliore . E così via come l'animazione continua .

Questo è un po ' teorica, dal momento che è in realtà fatto dal renderer . Secondo la fonte della classe bitmap, è solo un suggerimento, e il rendering può o non può onorare .

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

Io non sono del tutto sicuro del perché questo sarebbe particolarmente adatto per le icone delle applicazioni, però. Anche se Android su tablet, così come alcuni lanciatori ( es GEL ), richiedere un'icona " una maggiore densità " per mostrare più grande, questo dovrebbe essere fatto utilizzando il meccanismo di regolare ( cioè drawable-xxxhdpi, & amp; c ) .

4kreker @

Una cosa che ho già detto in un altro thread che vale la pena sottolineare - se si sta costruendo diverse versioni della vostra applicazione per diverse densità, si dovrebbe conoscere la directory risorsa " mipmap " . Questo è esattamente come risorse " disegnabili ", tranne che non partecipa strippaggio densità quando si creano i diversi target APK .

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