2015-08-20 6 views
9

Vor ein paar Tagen haben wir eine App im Play Store veröffentlicht, die sich mit qualitativ hochwertigen Bitmaps beschäftigt und alles über die Bearbeitung von ihnen.Nach bitmap.recycle(), oder nicht nach bitmap.recycle()

Alles lief gut, als wir feststellten, dass 20% der Geräte keine Speicherfehler mehr hatten. Also haben wir unseren Code überprüft und festgestellt, dass Android keinen nativen Speicher freigibt, der zum Speichern von Bitmap-Daten auf einigen Geräten verwendet wird. In diesem Fall haben wir den Befehl recycle begrüßt.

Die Speicherfehler verschwanden (zumindest in HD-Geräten). Wie auch immer, wir waren glücklich. Aber heute begannen wir zu sehen, dass 50% der Geräte begannen, einen weiteren Fehler zu geben: "Kann eine recycelte Bitmap nicht kopieren"

Wir waren enttäuscht. Auf zwei bitmap.copy() Linien in unserem Code, die Hälfte der Geräte können diese zwei Zeilen in synchronen nicht:

Bitmap anotherBitmap = bitmap.copy(bitmap.getConfig(), true); 
bitmap.recycle(); 

So wir das Recycling und die Freigabe ein weiteres Update entfernt, entschied sich die Gerätebildschirmgrößen zu begrenzen, so Kleine geben uns keine schlechte Bewertung.

Hier ist meine Frage. Warum können manche Geräte vor dem Recycling kopieren und die andere nicht?

Ich habe Googles Bitmap-Dokumentation gelesen und wusste bereits, wie Bitmap auf Heap und nativem Heap von vm gespeichert wird, wie Garbage Collection auf Speicherfehlern usw. funktioniert. Der Beispielcode, den Google zum Laden und Bearbeiten von großen Bitmaps bietet, ist nahezu wie unsere.

Lesen Sie viele Blogs, Google Group Threads, Github Code Beispiele ... Ich denke, ich brauche noch eine gute Dokumentation/Buch über Android-Bitmaps.

PS: Wir verwenden bereits inSampleSize, um Bitmaps zu skalieren, während sie dekodiert werden.

EDIT - Hier sind einige Daten aus den Crash-Berichte:

Alle Geräte sind nicht verwurzelt. In den meisten Fällen liegt der Speicher zwischen 25% und 35%.

Manufacturers: 
57% LG 
31% Samsung 
10% Casper Via V5 (Turkey based company, sells rebranded Chinese phones) 

Devices: 
81% LG D855 (G3) 
18% LG D802TR (G2) 
---- 
66% Samsung SM N910C (Galaxy Note 4) 
20% Samsung SM A700F (Galaxy A7) 

Operating Systems: 
68% Android 5 
31% Android 4 

OS 5 Details 
69% Android 5.0 
30% Android 5.0.1 

OS4 Details 
66% Android 4.4.2 
33% Android 4.4.4 
+0

Soweit ich mich erinnern kann, wenn ein Bitmap im nativen Speicher platziert hat, mit welcher Version von Android zu tun, speichern Sie laufen, neuere Versionen von Android nicht, sie in nativer ram und auf denen sollten Sie nicht recyceln müssen. Wenn es darum geht, was wirklich passiert, wenn Sie copy & recycle aufrufen, hängt es vom OEM-Hersteller und der Android-Version ab. Könnten Sie ein bisschen mehr Informationen zu Gerät und Plattform liefern? – JohanShogun

+0

Eine mögliche Vorgehensweise könnte sein, den Anruf nur auf Telefonen mit rothaarigem Bart oder früher anzurufen (wenn Ihre Daten, mit welchen Telefonen das Problem auftritt, die Idee unterstützen, dass die Telefone mit Speicherproblemen alle mit Pfefferkuchen oder früher laufen). – JohanShogun

+0

Was Dokumentation über Bitmaps angeht, ist es am schnellsten und einfachsten, zu überprüfen, wie aosp Dinge macht, einige Hersteller ändern die Dinge (Samsung ist der größte Übeltäter), aber es sollte dir genügend Informationen darüber geben, wie Dinge auf den meisten Geräten gemacht werden. leicht durchsuchbar aosp: http: // androidxref.com – JohanShogun

Antwort

0

Sind Sie wirklich sicher, dass

bitmap.copy (..)

nicht zweimal aus irgendeinem Grund genannt wird?

dh:

//first call Bitmap anotherBitmap = bitmap.copy(bitmap.getConfig(), true); bitmap.recycle();

[...]

// second call Bitmap anotherBitmap = bitmap.copy(bitmap.getConfig(), true); bitmap.recycle();

+1

ja. Recycling wird nur einmal verwendet. Wir verwenden diese erste Kopie für Effekte. Die zweite Kopie wird erstellt, um das bearbeitete Bild, das aus der ersten Kopie und nicht aus dem Original erstellt wurde, zurückzusetzen. Geräte mit der Nullzeiger-Ausnahme geben an, dass dieselbe Zeile der gleichen Klasse das Problem hatte. und nur ~ 50% der Geräte haben einen Absturz. das Bleiben hat kein Problem mit dem Recycling. Zur Zeit haben wir unseren Bearbeitungsworkflow geändert und alle Recyclinge entfernt. sehr wahrscheinlich werden wir Bild lesen nach ndk für bessere Speicherverwaltung verschieben, da androids gb ein Durcheinander ist, wenn es zu Bitmaps kommt. – emrahgunduz

Verwandte Themen