Activity mit vielen Buttons mit jedem Start langsamer

    Hallo zusammen,


    ich hätt´ da mal wieder ne Frage :) Und zeige ich in einer Activity u.a. wirklich viele Buttons innerhalb einer ScrollView an (programmatisch erzeugt), kann man sich als Tabelle vorstellen, ca. 30*30 Buttons. Bei ihrem ersten Aufruf ist das Ganze trotzdem noch sehr performant, man kann zB. flüssig scrollen.


    Wenn die Activity nun beendet wird (onDestroy wir aufgerufen) und anschließend neu gestartet wird, geht der Speicherbedarf der App immer weiter in die Höhe und die App wird immer unperformanter:


    GC_FOR_ALLOC freed 1762K, 6% free 39425K/41607K, paused 242ms


    Ist das nicht eigentlich ein Fall für den Garbage Collector? Ich meine ich muss mich doch an sich nicht darum kümmern, den von den Buttons belegten Speicher beim Beenden der Activity wieder frei zu machen, richtig? Aber irgendwie daran scheint es ja zu liegen....


    Grüße,
    FargoTof

    Hi,


    ist dein Problem jetzt dass er sich voll saugt bis er abraucht oder verschluckt er deiner Meinung nach zu viel Speicher?
    Wenns letzteres ist, nix für ungut, aber wozu bitteschön ist denn Arbeitsspeicher da? Solang noch genug frei ist muss sich das OS doch nicht unnötig stressen und frei schaufeln. Erst wenn er merkt oha jetzt wirds aber knapp werkelt er los und wirft weg. So solls sein und daran lässt sich auch nichts ändern, ausser du zapfst irgendwelche Taskkiller Apps o.ä. an die die ganze Speicherverwaltung zunichte machen.


    Gruß,
    matze

    Hi,


    ich verstehe ehrlich gesagt deine Frage nicht ganz ;) Ich würde aber mal mit "ersteres" antworten. Ich habs zwar bisher noch nicht auf die Spitze (sprich bis zum Absturz) getrieben, aber ich habe halt die Symptome:


    - Der Speicher wird immer voller
    - Das System / meine App wird immer unperformanter.


    Ob ersteres Symptom zweiteres bedingt, weiß ich nicht, könnte ich mir aber vorstellen. Frage ist nun: Wie beheben?


    Grüße,
    FargoTof

    Jedes View Element verbraucht Speicher, wenn man dann noch viele Sachen in das unperformante Linearlayout packt wird es richtig haarig, beim SDK ist ein Tool dabei was den Speicherbedar simuliert. Eventl musst du deine XML Layout mal überarbeiten.


    Man darf nicht vergessen, das wir immer noch auf einer mobilen Platform programmieren welche zwar schon lesitungsfähig ist, aber nicht die Performance einer Desktop-Workstation hat.

    Naja, dass ich vom Layout als solches kein Performance-Wunder erwarten kann, ist mir schon klar, allerdings läuft ja beim ersten Start noch alles hinreichend flüssig.


    Erst mit jedem Beenden und Neustarten der Activity wird der Speicher immer voller (und eben das verstehe ich halt nicht: Werden die Buttons beim Beenden nicht entfernt? Und falls nein: Warum werden sie es selbst dann nicht, wenn das Device offensichtlich überlastet ist?) und die App gleichermaßen immer träger...


    Kann man dem tatsächlich nicht entgegenwirken (das Löschen wirklich erzwingen, ...)?

    Hi,


    du kannst eigenltich nur versuchen größere Datenmengen auszulagern wie Hashtables oder ArrayLists die nur 1 mal initialisiert und befüllt werden. Ansonsten kannst du mit der Methode finish() dem System nur mitteilen, dass diese Activity jetzt nicht mehr gebraucht wird. Ist aber in keinster Weise eine Garantie, dass das System das Ding dann auch verwirft.
    Ist es denn eigentlich überhaupt notwendig deine zich Buttons jedes mal neu zu basteln?


    Gruß,
    matze

    Naja, ich erstelle sie halt aktuell beim Aufrufen der Activity, sprich in der onCreate. Und richtig, ich beende ja mit finish(), was offensichtlich wie du sagst nicht zwingend was nützt


    --> Wie könnte man des denn grundsätzlich überhaupt anders machen (also wenn ich sie nicht jedes mal laden will, muss ich ja woanders speichern...)?
    --> Von diesem Fall abgesehen: Meine Buttons repräsentieren u.U. bei jedem Start der Activity einen anderen Umfang an Daten, es muss also "dynamisch" entschieden werden, wieviele es sind, was bei Click passiert, ... spätestens dann kriege ich also auch bei "ausgelagerten" Daten Schwierigkeiten, oder? Blöd, blöd das...

    Hi,


    sorry für die späte Antwort ...


    Als grundsätzlichen Weg etwas auszulagern baue ich mir immer eine stinknormale Java Klasse. Einfach irgendeinen BeanHandler der Objekte erzeugen und statisch festhalten kann. Passieren denn bei 30*30 Buttons auch 30*30 unterschiedliche Dinge? Wenn nicht wäre es doch möglich jeden Button der etwas anderes tut als eigene Bean zu gestalten die nicht verworfen werden sondern einer statischen Liste angefügt. Oder man implementiert irgendein FIFO verfahren bei dem nach, ka, 50 Buttons immer der letzte raus fällt. Gibts glaub ich auch was fertiges. Beim erzeugen der Oberfläche muss man dann jedoch herausfinden welche Objekte man da jetzt recycelt und welche neu dazu gehören. Stellt sich jetzt die Frage ob das weniger Aufwand ist als einfach einen neuen Button zu bauen ....


    Glaub ich kann dir wohl nicht weiter helfen, sorry


    Gruß,
    matze

    Hey,


    danke für die Antwort! Leider habe ich sie nicht 100prozentig verstanden. Ich habe mir mittlerweile tatsächlich die Oberfläche etwas umgestaltet, sodass ich "nur" noch 3 Tabellenspalten und somit gute 100 Buttons habe + 2 weitere Buttons, mit denen ich dann durch die Tabelle "blättere", im Prinzip verwende ich also Buttons wieder und unterscheide deren Verhaltensweise dann über eine Variable, die mir sagt, wo ich hingeblättert habe.


    Das Problem bleibt aber soweit natürlich ungelöst, d.h. die Performance bleibt jetzt zwar etwas länger hinnehmbar, irgendwann gehts aber trotzdem bergab.


    Interessant wäre daher nochmal dein Lösungsansatz mit FIFO:


    - Damit ich Buttons wirklich wiederverwenden kann, also auch nach Neustart der Activity, müssten Sie ja auch außerhalb dieser gespeichert werden, richti? Wo denn am besten?


    - Auf welche Art und Weise könnte man denn dann immer "den letzten Button rausfallen" lassen, also so, dass er den Speicher auch wirklich freigibt? Weil exakt das ist ja eigentlich bereits jetzt mein Problem..


    Grüße,
    FargoTof

    Hi,


    das mit FIFO war ein "Schuss aus der Hüfte", ich bild mir ein es gibt irgendein Objekt das dem Vector ähnlich ist nur kann man dem im Konstruktor die Anzahl der Objekte die er aufheben soll mitgeben. Find jetzt leider aber auch nicht mehr wie das ding heißt ... sorry.


    Ich weiß irgendwie immer noch nicht wirklich was genau du eigentlich machst, 100 Buttons in einer einzigen Ansicht klingt so viel, kann man da überhaupt noch drauf drücken ohne 10 mal den falschen gedrückt zu haben frag ich mich ....


    Aber egal, du hast jetzt pro "Seite" 100 Buttons, die sind ja eigentlich jetzt fest oder? Nächste Seite wieder 100 Buttons, steht vll was anderes drauf aber is immer noch nur ein Button. Diese 100 Buttons könntest du ja jetzt in einen Vector<Button> werfen. Eine ganz normale Java Klasse erstellen, Singleton Pattern anwenden und dir dann immer schön statisch die Buttons raus ziehen und je nach Herzenslust andere Werte drauf setzen. Machst du sowas schon? Hast du sowas mal probiert? Bringts das von der Performance her? 100 Buttons halten is au scho eine nicht ganz unerhebliche Aufgabe möcht ich meinen. Probiers mal aus.


    Letztendlich weiß ich dann aber auch nicht mehr weiter. Wie killphil schon sagte, ist halt doch nur ein Handy ;)



    Gruß,
    Matze

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden