[Android/Java] Enkele problemen ivm met geheugen en images

[roel0]

Gegroet ik zit met enkele problemen/vragen ivm met programmeren voor android.

1) Eerst een algemene vraag die meerdere mensen wel zullen kunnen beantwoorden:
Als je naar games zoals angry birds kijkt of naar oude roms van vroeger, is hun totaal pakket altijd slechts enkele MB terwijl het toch zeer grote spellen zijn met een uitgebreide grafische verschijning. Als ik 1 afbeelding van al wat deftige kwaliteit wil toevoegen kom ik al aan gemakkelijke 1 MB voor die file zelf , hoe lossen ze dit op?

2) Ik kom maar neit toe met het voorgeschreven geheugen op Android. Ik ben bang dat ik met een Context leak zit , al snap ikd at nog niet genoeg om te weten waar hij zit. Mijn app draait enkel in portrait dus een leak door je GSM om te draaien kan het niet zijn, het moet dus een referntie zijn die ergens blijft hangen. Eigenlijk passeer ik maar 1 keer de context naar een zelfgemaakte Class en dat is de volgende:

code:

public class Graphics {
    private Context context;
    public Graphics(Context c) {
        context = c;
    }
    public Bitmap decodeFile(int file, int size) {
        BitmapFactory.Options o = new BitmapFactory.Options();
        o.inJustDecodeBounds = true;
        BitmapFactory.decodeResource(context.getResources(),file,o);
        int width_tmp = o.outWidth, height_tmp = o.outHeight;
        int scale=1;
        while(true) {
            if(width_tmp/2 < size || height_tmp/2 < size)
                break;
            width_tmp/=2;
            height_tmp/=2;
            scale*=2;
        }
        
        BitmapFactory.Options o2 = new BitmapFactory.Options();
        o2.inSampleSize = scale;
        return BitmapFactory.decodeResource(context.getResources(),file,o2);
    }
}

3) In mijn spel wil ik 3 a 4 afbeeldingen op het scherm posten ( achtergrond en enkele figuurtjes). Maar ik moet de kwaliteit met de bovenstaande functie heel hard verminderen ( heel hard ). Anders vreet het bijna al mijn geheugen weg. Nu refereer ik weer naar angry birds waar veel meer "afbeeldingen" op het scherm te voorschijn komen in een verbluffende kwaliteit. Hoe is dit mogelijk?

Alvast bedankt voor jullie hulp!
Mvg,
Roel

[CodeCaster]

Over welke resolutie en bestandstype hebben we het hier? Met 1 MB kun je behoorlijk wat.

[NMe]

Verbluffende kwaliteit valt ook wel mee. Daarnaast zitten er amper verschillende kleuren in de meeste grote afbeeldingen in Angry Birds, dus een PNG kan al snel winstgevend zijn. Sowieso zitten er bijna geen grote plaatjes in Angry Birds, hooguit de achtergronden en die zijn bijzonder ongedetailleerd. Als je meer dan 200-300KB kwijt bent aan een plaatje dan doe je iets verkeerd. Begin eens met "save for web & devices" als je met Photoshop werkt, of een vergelijkbare functie in andere programma's.

Wat betreft je context-probleem: ik durf niet te zeggen of je geheugenprobleem hier vandaan komt maar je zou het kunnen testen door de context als parameter aan de method mee te geven zonder hem op te slaan in het object. Sowieso oogt je class nogal statisch, als dit je hele class is zou ik niet eens de moeite doen hem instantieerbaar te maken.

[roel0]

De achtergrond is Bv 1024*658 en is ongeveer 1,5 mb groot en is een PNG dus ik doe duidelijk iets verkeerd Eens zien wat ik met Gimp kan aanvangen. Het wordt tijd dat ik eens wat meer verdiep in de grafische wereld want mijn kennis is daar ontzettend klein

De Class is geinstantieerd omdat ik hem vanuit verschillende activiteiten aanroep en later hoogst waarscheinlijk nog zal uitbreiden

[NMe]

Dan nog blijft mijn advies staan om eens te checken of het beter wordt als je de context middels de functie doorgeeft in plaats van middels de constructor. Je kan dan in elk geval bepalen of je leak daar zit.

Wat betreft het gebruiken van PNG: ja, die files worden groot als het veel verschillende kleuren zijn. PNG is dan ook lossless. Neem een JPEG van kwaliteit 8 en je ziet het verschil op de gemiddelde telefoon niet terwijl de bestandsgrootte vermindert tot een kwart.

[roel0]

NMe schreef op donderdag 05 januari 2012 @ 00:37:
Dan nog blijft mijn advies staan om eens te checken of het beter wordt als je de context middels de functie doorgeeft in plaats van middels de constructor. Je kan dan in elk geval bepalen of je leak daar zit.

Wat betreft het gebruiken van PNG: ja, die files worden groot als het veel verschillende kleuren zijn. PNG is dan ook lossless. Neem een JPEG van kwaliteit 8 en je ziet het verschil op de gemiddelde telefoon niet terwijl de bestandsgrootte vermindert tot een kwart.

Het schilt toch al 2MB in direct geheugen gebruik als ik het via de functie doorgeef , dat zal naarmate je langer in het spel zit wss nog opbouwen , dank je voor de hint!

Nu zal ik eens zien naar de Jpeg

Edit met de Jpeg geraak ik tot aan 100Kb zonder zichtbaar verlies! Waarvoor mijn zeer grote dank , weer iets bijgeleerd vanavond

[ Voor 8% gewijzigd door roel0 op 05-01-2012 00:45 ]

[NMe]

Hoe gebruikte je je Graphics-class precies? Toevallig op dezelfde manier waarop je hier de Context gebruikte? Dat zou wel een en ander verklaren namelijk, want dat betekent dat je Graphics-object in het geheugen blijft, wat weer betekent dat je Context in het geheugen blijft en dus bij contextswitches weglekt.

[roel0]

NMe schreef op donderdag 05 januari 2012 @ 00:45:
Hoe gebruikte je je Graphics-class precies? Toevallig op dezelfde manier waarop je hier de Context gebruikte? Dat zou wel een en ander verklaren namelijk, want dat betekent dat je Graphics-object in het geheugen blijft, wat weer betekent dat je Context in het geheugen blijft en dus bij contextswitches weglekt.

Graphics graphics = new Graphics(context);
Is dus volledig fout? Of bestaat er een manier oma chteraf deze referentie ongedaan te maken?

[NMe]

Nee, dat is niet fout. Maar dan weet ik zo even niet waarom de GC je Graphics-object niet opruimt aan het einde van de method waar die regel code staat.

[Stukfruit]

roel0 schreef op donderdag 05 januari 2012 @ 00:09:
1) Eerst een algemene vraag die meerdere mensen wel zullen kunnen beantwoorden:
Als je naar games zoals angry birds kijkt of naar oude roms van vroeger, is hun totaal pakket altijd slechts enkele MB terwijl het toch zeer grote spellen zijn met een uitgebreide grafische verschijning. Als ik 1 afbeelding van al wat deftige kwaliteit wil toevoegen kom ik al aan gemakkelijke 1 MB voor die file zelf , hoe lossen ze dit op?

Valt heel erg mee. Wat jij denkt te zien is niet wat er echt is. Om Angry Birds als voorbeeld te nemen:

• Het grootste deel van de blauwe lucht is heel waarschijnlijk gewoon een simpele opdracht via de teken-api om het scherm leeg te maken met een enkele kleur. Niets bijzonders, maar het legt de basis voor de rest van het beeld. Je kan hier eventueel ook een verloop van maken. Als dit te langzaam is kan je zo'n afbeelding ook voor het laden van een level maken zodat je de zaak niet ieder frame hoeft te blenden.
• Daarbovenop zie je wolken. Deze wolken bestaan uit niet meer dan een afbeelding en vijf kleuren. Met een PNG-optimizer kan je zo'n afbeelding enorm klein maken, zelfs minder dan een paar KB groot als je het goed doet. Als je goed oplet zal je trouwens ook zien dat de wolken eigenlijk uit een patroon bestaan dat zich herhaalt. De grote bolling aan de linkerkant van het scherm wordt ergens over de helft opnieuw getekend en dit geldt ook voor de rest van de wolken, die zich allemaal in dezelfde afbeelding lijken te bevinden. Met een beetje slim werken kan je deze hele bitmap half transparent maken zodat je gebruik kan maken van de achtergrondkleur en de wolken kan hergebruiken in meerdere levels en met verschillende kleuren.
• Bovenop de wolken komt het landschap. Dit bestaat uit meerdere losse lagen omdat deze afhankelijk van de rest moeten kunnen scrollen. Iedere laag is een aparte afbeelding. Ook hier geldt hetzelfde als voor de wolken: weinig verschillende kleuren, dus erg klein om op te slaan. Door iedere afbeelding van elke laag een afwijkende breedte mee te geven krijg je meer variatie en krijg je de illusie dat de bergjes en wolkjes allemaal verschillend zijn.
• Daaronder de grond. Dit is ook weer een zichzelf herhalende afbeelding met een afwijkende breedte. Kijk maar naar de stipjes en je zal zien dat het verderop ergens begint met herhalen.
• De gele/witte bloemetjes zijn onderdeel van de voorgrond en worden er gewoon bovenop opgetekend. Ieder bloemetje is heel erg klein op te slaan, zeker wanneer je dit samen met andere voorgrondattributen in een enkele afbeelding doet zodat er geen dubbele paletten en andere overbodige bestandsinformatie hoeft worden opgeslagen.
• De rest van de voorgrond bestaat uit oa. gras: een paar kleine bitmapjes die meerdere keren worden herbruikt. Een katapult: handvol kleuren, weinig data. Paaseieren: weinig kleuren.
• De obstakels (bv. de cirkels) op de voorgrond zijn opgevuld met een kleine schaakbordtexture die wordt herhaald. Dmv. projectie op de obstakels is dit erg simpel voor elkaar te krijgen, terwijl het er "ingewikkeld" uitziet.
• De bommen, varkens en karretjes nemen ook niet veel data in beslag, want: weinig kleur.

Zoals je ziet is het niet zo moeilijk, je moet alleen wel een beetje nadenken hoe je alles in stukjes gaat verdelen

3) In mijn spel wil ik 3 a 4 afbeeldingen op het scherm posten ( achtergrond en enkele figuurtjes). Maar ik moet de kwaliteit met de bovenstaande functie heel hard verminderen ( heel hard ). Anders vreet het bijna al mijn geheugen weg. Nu refereer ik weer naar angry birds waar veel meer "afbeeldingen" op het scherm te voorschijn komen in een verbluffende kwaliteit. Hoe is dit mogelijk?

Zie uitleg hierboven

Verdere uitleg:

• PNG: gebruik dit wanneer je hoge kwaliteit wil hebben, maar gooi het *altijd* eerst even door een optimizer heen. OptiPNG doet z'n werk bijvoorbeeld erg goed. Zorg er wel voor dat je goed met alle opties speelt om je bestanden zo klein mogelijk te maken.
• JPEG: persoonlijk zou ik hier ver bij uit de buurt blijven, tenzij je bv. foto's gebruikt. De compressie is te lelijk, zeker bij cartoony afbeeldingen. Niet gebruiken als je hoge eisen stelt aan de looks van je (cartoony) game.

[EddoH]

Iets wat verwarrend kan werken: er wordt hier gesproken over verschillende compressiemethoden om een plaatje minder ruimte in beslag te laten nemen. Dit bekend echter niet per sé dat er ook minder geheugen door de applicatie zal worden gebruikt. Het is belangrijk om verschil tussen diskruimte en werkgeheugen in acht te nemen.

Een JPEG die 80% gecomprimeerd is van 1MB naar 20kB zal bij het laden van de afbeelding door de applicatie waarschijnlijk nog steeds 1MB aan RAM in gebruik nemen, afhankelijk van wanneer de decompressie plaatsvindt.

Om het plaatje te teken zal er (vaak) toch echt gedecompressed moeten worden en neemt de afbeelding zo veel geheugen in als de resolutie * de bitdepth.

[Jegorex]

EddoH schreef op donderdag 05 januari 2012 @ 13:42:
Om het plaatje te teken zal er (vaak) toch echt gedecompressed moeten worden en neemt de afbeelding zo veel geheugen in als de resolutie * de bitdepth.

Dit dus.
Geen grote afbeelding gebruiken als achtergrond (omdat het er ook goed uit moet zien op een tablet?), maar een paar kleine afbeeldingen die vaak herhaald worden en samen de achtergrond vormen.

[roel0]

Jegorex schreef op donderdag 05 januari 2012 @ 14:15:
[...]

Dit dus.
Geen grote afbeelding gebruiken als achtergrond (omdat het er ook goed uit moet zien op een tablet?), maar een paar kleine afbeeldingen die vaak herhaald worden en samen de achtergrond vormen.

Dat ik daar niet aan gedacht heb

Allemaal zeer bedankt voor jullie hulp , deze avond zal ik jullie ideeën in praktijk omzetten.

Mvg,
Roel

[NMe]

EddoH schreef op donderdag 05 januari 2012 @ 13:42:
Iets wat verwarrend kan werken: er wordt hier gesproken over verschillende compressiemethoden om een plaatje minder ruimte in beslag te laten nemen. Dit bekend echter niet per sé dat er ook minder geheugen door de applicatie zal worden gebruikt. Het is belangrijk om verschil tussen diskruimte en werkgeheugen in acht te nemen.

Voor wie is dat verwarrend dan? Want de topicstarter had drie vragen. Twee daarvan gingen over opslaggrootte en eentje over geheugen.

[EddoH]

NMe schreef op donderdag 05 januari 2012 @ 15:38:
[...]

Voor wie is dat verwarrend dan? Want de topicstarter had drie vragen. Twee daarvan gingen over opslaggrootte en eentje over geheugen.

Voor de topicstarter, aangezien er bij de reacties niet bij werd gezegd of dit zowel opslagprobleem als geheugengebruik van de applicatie zou kunnen oplossen en ik het gevoel kreeg dat de TS niet genoeg ervaring hiermee had om het verschil zelf te kunnen opmerken

[Armageddon_2k]

Jegorex schreef op donderdag 05 januari 2012 @ 14:15:
[...]
Geen grote afbeelding gebruiken als achtergrond (omdat het er ook goed uit moet zien op een tablet?), maar een paar kleine afbeeldingen die vaak herhaald worden en samen de achtergrond vormen.

Je zit dat dit bij websites ook vaak wordt toegpast, stel je hebt een 3D vormgegeven knop. Deze word vaak in 3 delen gemaakt.
Links midden Rechts
Het midden deel is super smal en wordt gewoon een x aantal keer herhaald.
Je kijgt dan:
LMMMMMMMMMMMMMMR

[NMe]

Pssst, sliding doors.

[roel0]

Nog een zeer domme fout eruit gehaald die het geheugen opeistte:
- In een functie drawText kon een font meegegeven worden die in de functie lokaal geladen werd , deze functie werd door onDraw zeer veel aangeroepen.

Aldoende leert men zal ik maar zeggen