lite blandade frågor

Hej!

Första post, såg denna sajten när jag kollade rundor nån dag, verkade som att det fanns kunnigt folk här. Jag har 2 funderingar jag har samlat på mig under en tid, som inte är så besläktade med varandra.

1. Jag håller på att utveckla en relativt simpel recept-app till en kompis flickvän, kommer väl kanske lägga upp den här på forumet när jag känner mig klar med den. Iallafall så finns det i den en WebView som hämtar relativt stora bilder ( ungf 400kb ), dessa cachas på SD-kortet (om ett sådant existerar). Min fråga är följande:
Finns det nån 'praxis' gällande hur mycket data man ska cacha på SD-kortet utan att appen blir för 'krävande'? Min tanke har varit att användaren kanske ska kunna ställa in hur mycket data den vill cacha på SD-kortet, men detta kanske är för mycket finlir för en 'vanlig' användare? Kanske ha ett lågt defaultvärde, men att man ska kunna höja det mycket om man absolut vill undvika att ladda hem data i onödan? Skulle uppskatta några kloka tankar/erfarenheter om detta.

2. Min andra fråga är mer generell, om Androids minneshantering. Jag har läst på lite om den, om dalvik heap och native heap. Jag blir dock inte riktigt klok på hur mycket minne iallafall min telefon säger att den använder. När jag kollar i DDMS säger den att dalvik-heapen tar ca 10.5 MB som mest. I appmenyn (i inställningarna på telefonen) säger den dock att att den tar upp emot 29MB ( jag har en SE Live with walkman om det skulle göra nån skillnad ).
Är allt detta minne den delar med andra processer, eller vad? Jag kan inte tänka mig att 15MB+ skulle ligga i nativeheapen, alla bitmaps ligger väl i dalvikheapen nuförtiden som jag förstått det? Jag har sökt rundor ibland men inte hittat nåt bra svar till detta. Skulle vara mycket hjälpsamt om nån kunde förklara detta, eller peka på en artikel som gör det kanske.

 

1. Det du vill undvika är att lagra mer information än vad användaren känner till att du lagrar. Genom att ha en inställning och ett lågt default-värde så löser du det.
Varför behöver du ta hem så stora bilder? Nu är iofs inte 400k jättestort, men om du laddar upp några stycken såna samtidigt så tar det några sekunder och blir kanske inte jättesnyggt i GUI:t. Om det är bilder på maträtter eller bakelser så behöver de inte vara så stora. Det bör räcka med runt 20kB. Mitt tips är att ha en liten bild som laddas snabbt med en storlek som är anpassat till GUI:t och ladda ner en stor version då användaren begär det genom att klicka på bilden.
Om det inte känns som en key feature att kunna ladda alla upp bilder blixtsnabbt så skulle jag undvika att lagra dem. Om man sedan ser att den funktionen är viktig för användarupplevelsen så lägger man till den när allt annat är klart eller i en senare release.

2. Vad är det för problem du har eller vill lösa?
Jag känner inte till hur minneshanteringen fungerar så jag kan inte ge något direkt svar på det, men kanske kan hjälpa till om jag förstår vad du är ute efter.

 

Angående 1, så tycker jag det låter rimligt den principen du säger. Jag håller också med dig om att bilderna är för stora, problemet är att det är jag har att arbeta med i dagsläget, finns en stor bild och en liten bild, och den lilla är för liten för att ge nån översikt. Jag har inte heller nån kontroll över serverinnehållet, så jag har försökt göra det bästa av situationen. Det jag skulle kunna göra är kanske att försöka få min kompis att fixa bilder i lagom format, ska undersöka det senare.

Angående 2, så vill jag veta framförallt för att ha nån koll på hur mycket minne min app egentligen tar, så jag vet hur långt jag har kvar tills appen dör pga OOM-kill. Jag kan för närvarande inte kolla nativeheapen på min telefon, så det är svårt att veta hur mycket den egentligen tar tycker jag, för de siffrorna OS:et säger verkar orimliga.
Om man bortser från det är jag också sjukt vetgirig emellanåt och vill förstå allt, så det är också en anledning till att jag vill veta.

 

Om du har en funktion för att spara favoriter kan du ju då med fördel spara bilden när användaren har favoriter och bara ladda ner när man "browsar". Som e7andy skrev, ha helst mindre bilder om möjligt.

Du kan också cacha de recept som visas ofta och skippa de som visats endast en gång eller sällan.

Om du har en egen server kan ju enheten skicka sina specs till servern och då kan den avgöra hur stor bilden som ska skickas ska vara. En gammal ldpi enhet kan ju med fördel få en mindre bild och det kan fortfarande se bra ut medan en mdpi/hdpi platta med HD-upplösning kan få en (lite) större.

(Skrev detta innan jag läste din andra post så skäll inte på mig snälla )

Gällande punkt 2, du har säkert stött på detta redan men here goes:
http://android-developers.blogspot.se/2011/03/memory-analysis-for-android.html

 

Jag gillar dina idéer i princip, det där med favoriter hade jag glömt bort att fundera på hur jag skulle implementera det, tack för att du påminde mig. Jag ska som sagt försöka få tag på min kompis och åtminstone få honom att ha en till bilduppsättning på servern, en som är ungefär samma som jag använder nu men kanske minst hälften så stor. Min tanke är att träffa nån sweetspot, där bilden ser snygg ut på en stor/hdpi-skärm men är ganska liten så den inte behöver skalas ner så mycket för små skärmar.
En annan tanke jag haft är att alltid tanka de stora bilderna, men att skala ner dem i appen och spara dem i mindre format. Jag orkade dock inte undersöka det alltför noggrant, och när jag insåg att WebView hade sitt eget cachesystem, som gjorde att jag slapp implementera något sånt själv, använde jag det istället. Det hade ju inte varit svårt i princip, jag har ju i princip gjort ett cachesystem för de små bilderna redan, men WebView är som sagt väldigt bekvämt att använda.

Angående den där artikeln har jag nog stött på den någon gång ja, men den är väldigt läsvärd. Tyvärr beskriver den ju inte systemet i detalj, misstänker att man får rota i Androids/Linux minnessystem för att hitta svaret. En enklare fråga att besvara skulle kanske vara om dalvik-heapens storlek ungefär motsvarar appens 'reella' minnesanvändning ( med det menar jag det som räknas för att avgöra om en app får en OOM-kill eller ej) , förutsatt kanske att man använder android 4.0+ och inte använder OpenGL eller nåt liknande kanske? Har inte läst på om just den biten, men gissar att OpenGL skulle kunna använda sig av nativeheapen lite mer än andra delar av systemet.