Eindeloze activiteitenschema

In mijn app is er de mogelijkheid om een ​​eindeloze activiteitenstapel te hebben. Het scenario is dat u begint op de pagina van één gebruiker die een lijst heeft van mensen die "vrienden" van die gebruiker zijn. U kunt vervolgens op een vriend klikken om naar zijn pagina te gaan, die er net zo uitziet als de vorige, waar u vervolgens op een andere vriend kunt klikken om naar zijn pagina te gaan, enzovoort ...

Het grote probleem waar ik voor sta is een eindeloze inheemse hoop. Ik geloof dat ik elke keer weer aan deze hoop toevoeg dat een blik is opgeblazen. Na een paar iteraties hiervan, krijg ik constant OOM-fouten, dus ik moet een oplossing vinden. De truc is, ik wil de laatste paar activiteiten minimaal houden voor het navigeren door een bepaalde geschiedenis.

Het beste dat ik kan verzinnen, is het volgen van de activiteitenstapel en vervolgens beginnen met het beëindigen van activiteiten wanneer het een bepaald punt bereikt. Klinkt dat als een gedegen aanpak, of kan iemand me verder wijzen op een implementatie van die of een andere aanpak?

Bedankt

Bewerk:

De stapel is heel eenvoudig. Klik op een listrow (een vriend), ga naar hun pagina. Dit gebruikt een normale startActivity-aanroep met een intentie naar dezelfde pagina waarop u zich bevindt, en een intentie extra met de gebruikers-ID die vervolgens de database of een externe api-oproep zal bellen om de gegevens van de gebruiker te krijgen.

Ook om follow-up over Dalvik vs Native, ik routinematig controleer de meminfo dump tijdens mijn navigatie. Ik houd de dalvik-hoop zo klein mogelijk en ruim de middelen in onStop op. De inheemse hoop groeit veel sneller. Ik heb nergens een harde referentie naar bitmaps, maar nogal wat drawables op het scherm van inflations. Zouden deze drawables ertoe leiden dat android mijn activiteit uiteindelijk zou doden? Zo goed als ik kan vertellen, leiden ze gewoon naar OOM zonder dat al mijn activiteiten preventief worden vernietigd.

Als ik mijn activiteiten handmatig zou kunnen vernietigen in plaats van ze alleen maar te stoppen (zoals Android beweert te doen wanneer het geheugen bijna op is) en de vernietigde activiteit op de stapel te houden met de opgeslagen staat, zou dat ideaal zijn.

opnieuw bewerken:

een andere sleutel is dat deze activiteiten andere activiteiten met zich mee zullen laten nemen, b.v.

user -> user -> activity a -> user -> activity b -> user

dus daarom wil ik gebruik maken van de ingebouwde stack, dus ik weet wanneer ik naar een gebruikersactiviteit moet gaan en wanneer ik dat niet doe.

0
hoe precies implementeert u uw "stapel" van gebruikerspagina's?
toegevoegd de auteur josephus, de bron

2 antwoord

hoe zit het met het maken van deze activiteit singleInstance , onderschep KeyEvent.KEYCODE_BACK, bouw eigen back-knopstapel voor deze activiteit

ik heb hier een voorbeeld gemaakt:

http://esilo.pl/selvin/endlessactivity.zip

1
toegevoegd
download nieuwe versie (uit dezelfde bron) ... ik vergat om setIntent (intent); in public void onNewIntent (Intent intent) toe te voegen (zonder het als je de oriëntatie wijzigt je raakt de backstack kwijt)
toegevoegd de auteur Selvin, de bron
een goed idee (en een upvote voor dat), maar mijn behoeften zijn een beetje ingewikkelder. Iets wat ik heb verwaarloosd om te vermelden is dat deze activiteiten andere activiteiten met zich mee zullen hebben, hierboven bewerken om dat weer te geven
toegevoegd de auteur Jonathan S., de bron

Ik denk niet dat het OOM-probleem dat je ervaart verband houdt met het aantal activiteiten dat je hebt geopend. Android zou alle oude activiteiten op de achtergrond moeten vernietigen naarmate de geheugendruk toeneemt. Deze activiteiten worden dan gewoon opnieuw gemaakt wanneer de gebruiker terugkeert door de taakstapel.

Heeft u een tool als MAT (geheugenanalysetool) gebruikt om te onderzoeken wat u tijdens de looptijd van uw toepassing hebt toegewezen? Ik vermoed dat je een geheugenlek hebt of dat je misschien slimmer moet zijn in je geheugentoewijzingen.

0
toegevoegd
Nou, ik zou verwachten dat zowel native als dalvik omhoog gaan totdat een GC wordt uitgevoerd. Als het grootste deel van je geheugen inheemse kant is toegewezen, denk ik dat je gelijk hebt in je veronderstelling dat Dalvik daar niet op zal reageren. Het klinkt alsof je het meeste werk doet aan de native kant. Weet je zeker dat je opschoonactie correct werkt, omdat onStop moet worden opgeroepen voor een activiteit wanneer je naar de volgende in de stapel gaat.
toegevoegd de auteur Justin Breitfeller, de bron
Ja, het zou meer nuttig kunnen zijn voor anderen als je meer post over wat je doet, native VS in Dalvik in je vraag, omdat NDK echt buiten mijn expertise ligt. Ik weet wel dat je niet moet proberen drawables tussen activiteiten te houden, tenzij je heel voorzichtig bent over hoe je ze losmaakt van je activiteit. Zie android-developers.blogspot.com/2009/01/avoiding-memory-leak‌ s.html over dit onderwerp.
toegevoegd de auteur Justin Breitfeller, de bron
Ik heb MAT gebruikt en ben ook voorzichtig geweest met het vrijgeven van middelen op Stop. Kijkend naar de meminfo dump terwijl ik dieper navigeer, gaan zowel native als dalvik omhoog. Zal het systeem een ​​activiteit ook doden vanwege een probleem met de native heap? Ik dacht dat dat apart was ...
toegevoegd de auteur Jonathan S., de bron
Mijn opruiming werkt, maar het is misschien niet grondig genoeg. Ik ruim de lijsten op en geef prullenbakken weer om van de rijen af ​​te komen, maar de andere weergaven zijn intact, wat betekent dat alles buiten mijn lijst de tekentafel behoudt (knoppen, achtergronden, koptekstafbeeldingen, enzovoort). Ik vermoed dat dit de reden is waarom de inheemse hoop gewoon omhoog blijft gaan, elke keer dat hij deze drawables opblaast zitten ze daar gewoon. Dus zoals ik het zie, moet ik ofwel al mijn views onstop maken (wat lijkt op overkill) of de grootte van mijn activiteitenstack regelen. Als ik kon zien wat er in mijn geboorteplaats lag, zou ik meer zelfvertrouwen hebben.
toegevoegd de auteur Jonathan S., de bron