Führt Android Dalvik/ART eine komprimierung von Bitmaps durch

Ich habe mich mal gefragt wieviel speicher eine sagen wir mal 256x256 bitmap verbraucht?

logischerweise würde ich denken 65.536 * x bits(x für 16,32,64 je nachdem wieviel info ein pixel hat->gibt es eine feste Anzahl für die bitlänge eines pixels bei Android wäre die nächste frage oder hängt es ab von hardware bzw ressourcenquelle)

da ja bildressourcen(.png etc.) immer komprimiert werden frage cih mcih ob das android nciht vielleicht auch so macht?!
wäre bestimmt von vorteil für die laufzeit wenn das bitmap erstmal geladen ist und auch für den speciherverbrauch wenn sagen wir mal die datei nur aus einer farbe ebsteht dann wäre der ramm quasi nur mit einem pixel mal auflösungsbit gefüllt das hätte schon was

was sagt ihr?

Wie ein Pixel zusammengesetzt wird, kannst du (in gewissen Grenzen) bestimmen:
-> Bitmap.Config | Android Developers

Und mit den Methoden getByteCount() bzw. getAllocationByteCount() kannst du genau herausbekommen, wie groß dein Bitmap im Speicher ist.


Ständiges, verlustfreies(!) (De-)Komprimieren wäre aber eine hohe Last für die CPU und geht damit auf Akkulaufzeit - zumal du für die Anzeige oder Weiterverarbeitung dann doch wieder die unkomprimierte Variante im Speicher vorhalten musst. Freier Speicher ist heutzutage dagegen "billig"/"billiger". Kommt natürlich immer darauf an, wie das Gerät tatsächlich gebaut ist, wie viel noch parallel läuft und was man mit den Bildern vorhat. Bild- bzw. Videomanipulationen gehören definitiv zu den Speicher- und CPU-hungrigeren Anwendungsfällen.

ah okay wie ich es mit gedacht habe...ich kenn mcih zwar nciht so aus mit kernels und computer architekturen allgm.(was ich auf ejden fall im studium nachholen werde) aber das ganze system müsste dann also so ausgelegt sein dass es bitmaps lesen und verarbeiten kann ohne zu dekomprimieren-> dachte es könnte so ablaufen: lade aus komprimierter resource die informationen und verarbeite diese komprimiert weiter....

Das hängt davon ab, was du mit der Resource machen möchtest.

Beispiel: Für JPGs gibt es Algorithmen, die sie um 90/180° drehen können, ohne sie zu de- und neukomprimieren.
Willst du aber einzelne Pixel verändern, wird das schon nicht mehr gehen. Spätestens für die Darstellung brauchst du sie in unkomprimierter Form im Grafikspeicher.

Letztendlich ist es eine Rechnung, die man immer mit irgendwas erkauft wird. Soll es schnell (und teilweise auch flexibel) sein, braucht man (viel) Speicher. Soll es kompakt sein, muss die CPU oder I/O mehr leisten. Das gilt es dann im Einzelfall abzuwägen. Aber das geht schon in Richtung Optimierung von Speicher/CPU-Bedarf, weniger wie Android bzw. Java intern mit Bitmaps hantiert.

Thyrion schrieb:

Spätestens für die Darstellung brauchst du sie in unkomprimierter Form im Grafikspeicher.

Zum Vergrößern anklicken....

Ok das iese Antwort reciht mir darauf war ich im Endeffekt nur aus Danke

Ist eigentlich ganz einfach. So bald du anfängst Bilder zu verarbeiten, brauchst du Bitmap. In der kompletten Größe. Was aber kein Problem ist, da man bei aktuelleren Devices bis 250 MB Speicher reservieren kann (Galaxy Tab 2). So um die 10 Bitmaps geht eigentlich immer.

10 bitmaps sind etwas wenig also du meinst dann schon richtige Propper von 5000x5000 hoffentlich oder?