“La toile: en essayant de tirer trop grande image” quand Android N Taille de l'Écran plus grand que les Petites

J'ai publié un app qui crash au démarrage sur Android N lors de l'introduction du nouveau Display size OS paramètre est réglé sur une valeur trop élevée.

Quand je regarde dans le logcat, je vois le message suivant:

java.lang.RuntimeException: Canvas: trying to draw too large(106,975,232 bytes) bitmap.

J'ai tracé la question à un ImageView dans ma première Activité qui montre une belle et grande image de fond. L'image en question est 2048x1066 et il est à mon générique drawables répertoire, donc, peu importe la densité, cette image sera utilisée.

Tout fonctionne ok lorsque le Display size paramètre est Small. Mais quand je vais à la Default, il s'arrête de fonctionner. Si je puis permuter l'image avec un plus petit, il travaille à Default, mais si je vais à la Large, il s'arrête de fonctionner à nouveau.

Ma conjecture est que le réglage d' Display size des causes de votre appareil de se comporter comme un physiquement plus petit appareil avec une haute densité de pixels. Mais je ne comprends pas ce que je suis censé faire ici. Si je mets de plus en plus petits des images pour progressivement les grandes résolutions, il ne sera pas l'air bien sur la réalité de la grande affiche. Ou je ne suis pas à comprendre quelque chose?

Tous les pointeurs serait grandement apprécié.

  • "L'image en question est 2048x1066 et il est à mon générique un drawable répertoire, donc, peu importe la densité, cette image sera utilisée" -- res/drawable/ est synonyme de res/drawable-mdpi/. Si vous voulez l'image pour ne pas être mis à l'échelle basée sur la densité, l'utilisation res/drawable-nodpi/ ou res/drawable-anydpi/.
  • Merci pour la réponse. Je suis un peu confus, mais. Je pensais que les diverses res répertoires simplement permis à l'OS pour sélectionner la ressource appropriée, qui peut être étiré et écrasé par la mise en page selon le cas. Vous dites qu'une 100x100 pixel de l'image de la vie dans les différents répertoires de ressources est en fait mis à l'échelle pour créer un virtuel différents résolution version de celui-ci avant de passer à la mise en page? Qui pourrait certainement expliquer des choses, si vous avez eu le plus près de la limite de l'image qui les a mises à l'échelle par le système.
  • "Vous dites qu'une 100x100 pixel de l'image de la vie dans les différents répertoires de ressources est en fait mis à l'échelle pour créer un virtuel différents résolution version de celui-ci avant de passer à la mise en forme?" -- cela dépend de ce que densités vous avez et ce que l'appareil vous sont en cours d'exécution sur. Si il y a une correspondance exacte, rien n'est rééchantillonné. Si il n'y a pas une correspondance exacte, une voisine de la densité de l'image est rééchantillonné. Donc, si vous n'avez res/drawable/foo.png (un.k.un., res/drawable-mdpi/foo.png), et que votre appareil est xhdpi, l'image sera doublé sur les deux axes, à prendre 4 fois plus de mémoire.
  • Le 106975232 valeur dans votre erreur se trouve être exactement 49x la résolution de l'image, ce qui implique 7x rééchantillonnage le long des deux axes. C'est beaucoup plus que je l'aurais imaginé. Je n'ai pas eu la chance encore de jouer avec la taille de l'écran paramètres Android 7.0, donc je vais ajouter ça à ma toujours croissante de la liste de choses à faire...
  • Belle prise sur le 49x! Je pense que je peux expliquer pourquoi il est si haut. Gardez à l'esprit que ce nombre est d'octets. Cette image est de 24 bits, mais c'est probablement lu dans l'32 bits par pixel. Que ferait-il 8732672 octets en mémoire, ce qui va dans ce chiffre exactement 12.25 fois, ce qui implique de 3,5 x mise à l'échelle le long de chaque axe. Cet appareil est xxhdpi, de sorte que semble comme il pourrait être sujet de droit. De toute façon, je n'avais aucune idée de ressources, il faudrait être redimensionnées comme ça. Merci pour l'aide! (En passant, le déplacement de l'image à drawable-nodpi, en effet, de le corriger.)
  • Bonne explication de nodpi contre anydpi ici: commonsware.com/blog/2015/12/21/nodpi-anydpi-wtf.html
  • Vous devriez vraiment accepter la réponse de johan
  • Comment avez-vous comprendre ce que l'image qu'il a été? J'ai un problème similaire rapporté dans la nature avec aucun de mes code dans la pile, et j'ai du mal à comprendre où est le problème.

InformationsquelleAutor Brian Rak | 2016-08-23
  1. 137

    J'mon cas, le déplacement de l' (hi-res) splash bitmap à partir d' drawable à drawable-xxhdpi était la solution.

    J'ai eu le même problème. Je ne soupçonnais pas mon écran de démarrage pour être le problème, car il est s'affiche lorsque l'application est lancée, mais il s'est avéré que l'écran de démarrage est le problème.

    L'écran de démarrage dans mon cas a xxhdpi résolution, et il a été malencontreusement placé dans le drawable dossier, au lieu de drawable-xxhdpi. De ce fait Android assumer l'écran de démarrage a mdpi de la résolution et de l'image à l'échelle 3*3 fois, il est nécessaire de taille et d'essayer de créer une image bitmap.

    • je devine: donc, android échelle d'une image de xxhdpi à hdpi par exemple à une image plus claire? comme vous l'avez dit, à partir de 3*3 -> 1/1 à 1/3 par exemple?
    • Comme kalsara Magamage notes, c'est maintenant mipmap-xxhdpi.
    InformationsquelleAutor Johan Franzén
  2. 11

    Je ne sais pas serait-il aider quelqu'un, mais je vais le laisser ici.
    Dans mon cas le problème est uniquement sur Sumsung appareils avec Android 7, et le problème était dans l'écran de démarrage proportions. après la modification de la hauteur de 1024 px - tout fonctionne bien

    • Mon problème a été bitmap (jpg, png) dans drawable (sans suffixe) dossier. C'est la stupidité de ma part, mais peut-être que ça aide quelqu'un 🙂
    • C'est utile! Même problème que Samsung... Qu'avez-vous en premier et Comment avez vous résolu ce problème ?
    InformationsquelleAutor kazimad
  3. 10

    J'ai résolu le problème après l'ajout du code ci-dessous dans le fichier Manifeste de l'application de la balise entre android: lignes.

    android:hardwareAccelerated="false"
    • Bien, après avoir passé quelques heures cette solution fonctionne pour xiaomi et Samsung mobile problèmes.
    InformationsquelleAutor CHAMCHOUN
  4. 9

    Déplacer votre image dans le drawable de mipmap-xxhdpi.Votre image est au format bitmap, donc, vous devriez mettre votre image dans mipmap dossier,ensuite, il sera

    InformationsquelleAutor kalsara Magamage
  5. 3

    Essayez d'utiliser un Bitmap.Usine de classe, ce lien va vous aider à
    Le Chargement D'Un Grand Bitmaps Efficacement

    InformationsquelleAutor Khalid Ali
  6. 2

    si vous utilisez Picasso changement de Glisse comme cela.

    Supprimer picasso

    Picasso.get().load(Uri.parse("url")).into(imageView)

    Changement Glide

    Glide.with(context).load("url").into(imageView)

    Plus efficace

    InformationsquelleAutor Deniz
  7. 0

    L'icône fichiers sont trop gros pour Android, efficacement et en douceur de la charge. Android reconnaît cette avec ses algorithmes intelligents.

    Vous pouvez redimensionner l'icône des fichiers à l'aide Final Android Resizer par asystat. De les redimensionner pour "xhdpi" ou moins.

    Placer les photos redimensionnées dans drawable ou écraser sur la grande icône des fichiers.

    Alors, vous avez terminé.

    InformationsquelleAutor lloydyu24
  8. 0

    si vous êtes à l'aide de la glisse et vous êtes chargement 1k d'images à un moment ou certaines images puis il est question de la glisse ou de ce que vous faites à utiliser pour définir l'affichage de l'image. vous pouvez le résoudre en appliquant le type d'échelle dans la finesse.

    InformationsquelleAutor Deepak Rajput
  9. 0

    Dans mon cas, j'ai juste changé le canevas de l'image qui est utilisée dans l'arrière-plan à l'aide de Paint3d(ou vous pouvez utiliser n'importe quel autre). Ici, je vais partager une capture d'écran juste aller à travers elle.

    • Veuillez utiliser les commentaires pour partager vos idées.
    InformationsquelleAutor Vishaljoshi007