Beiträge von nono124

OK jetzt arbeitest du mit androidx.

Auch in dem anderen thread habe ich dich am Anfang gefragt für oder unter welcher Android Version du arbeitest. Das war für dich wider mal unwichtig unrelewant wie du behauptest.

Wie sieht den dein gradle file vom alten Projekt aus.

Zitat

Laut Doku soll das das Gleiche sein . System.rc ruft intern auch Runtime.getRuntime().gc(); auf.

Wo steht das bitte Quelle angeben.

Auch wenn es in den meistens Java Dokus so steht. Ist es doch immer von der JVM abhängig.
Jede JVM setzt das ein wenig anders um.
Deshalb beziehe dich immer auf die Android Doku. Da haben wir die Dalvik JVM.

https://developer.android.com/…s/verifying-apps-art.html
https://developer.android.com/reference/java/lang/System#gc()

das steht das es System.gc() fast gleichwertig ist zu Runtime.getRuntime().gc() is.
aber eben nur Fast.
Beim Test siehst du die Unterschiede.

Das es nicht das gleiche Verhalten ist kannst du in meiner app sehen und testen. Hast du das überhaupt?

Hallo

Dann setze deine Anfasser (Constraints ) richtig.
Beim Text hast du den Linken am Rand , den Rechten auch am Rand, Den Oberen auch oben am Rand. Soweit Richtig.

Bei deinem Button hast du nur zwei
Den rechten am rechten Rand, den unteren am unteren Rand.

Setze alle, also auch den linken an den linken Rand .
Wichtig den oberen an den Text.

app:layout_constraintTop_toTopOf="@+id/editText_TaskShow"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintBottom_toBottomOf="parent"

Das Freigeben des Speichers findet bei ca 70% statt aber meistens erst dann wenn Speicher angefordert wird.

Wenn beim App Start schon 50% belegt ist das schon viel.

Wie du den Speicher sehen kannst und wie du den GC auch selber auslösen kannst, kannst du dir in meinen Code ansehen.

Post NR.18 wenn du das nicht ansiehst und testest deine Schuld.

Runtime.getRuntime().gc();

https://stackoverflow.com/ques…thod-in-ondestroy-of?rq=1

Hier ein Beispiel:
A gestartet : 36,0 MB
A startet B : 36,6 MB
B zurück zu A 36,8 MB
A startet B: 36,9 MB
B zurück zu A 37,0 MB
A startet B 37,1 MB

Ist ja nicht viel was da verbraucht wird.

Wenn du dir mein Beispiel angesehen hattest wüsstet du wie der GC arbeitet und was du machen kannst um den GC dazu zubringen den Speicher aufzuräumen wann du willst und nicht wann er will.
System.gc() ist Standard Java und nicht Android.

Zitat

Es hat nicht geholfen, weil es gar nicht der von mir allokierte Speicher ist, der das Problem verursacht, also hilft es auch nicht, den von mir allokieretn Speicher auf null zu setzen oder sonstwas damit anzustellen.

Was ist mit deinem Adapter da wirst du einiges verbrauchen.

Zitat

Wie sich ein Garbage Collector verhält, weiß ich.
Das ist auch irrelevant.

mit sicherheit nicht sonst wärst du nicht hier.

Zitat

Er müsste entweder zyklisch vom System aufgerufen werden , oder bei bestimmten Ereignissen ( wie zu Beispiel wen eine App zerstört wird) und dann Speicher, der nicht mehr referenziert wird freigeben.

so einfach ist es eben nicht und auch versions abhängig.
aber du glaubst es hat nicht.

noch mal ich habe dich gefragt zu wieviel Prozent der Heap voll ist.
nochmal frage ich nicht.

ich hoffe immer noch das du nicht mit eclipse arbeitest.

mein Programm hast du dir bestimmt auch nicht angesehen und getestet.
dann würdest du sehen wie sich der GC verhält.

Zitat

und der Speicherverbrauch steigt und steigt bei jedem Umschalten.
Es tut mir Leid, aber für mich sieht das nach einem Android Bug aus.

Nein ein Bug ist das mit Sicherheit nicht.

Du solltest dir mal überlegen was alles bei dem Umschalten gemacht wird. Es werden Methoden und Kassen aufgerufen die du gar nicht Siehst. Das System braucht sozusagen auch Speicher zum Umschalten .

Das ist selbst in meinen Beispiel so wenn du öfters nur auf anzeigen Klickst.

Wie Ich schon mehrfach sagte macht der GC nicht immer gleich den Speicher frei sondern erst wenn er knapp wird .
Wie das der GC und wann der das macht ist auch Android Version und Geräte abhängig.

Außerdem solltest du wissen das wir in Java „Call by Value“ haben und nicht „Call by Referenz“ wie in C.
Was bei einem Methoden Aufruf meist etwas mehr Speicher verbracht als bei C.

Da Mobile Geräte nicht so viel Speicher haben als Desktop Rechner. Ist es üblich geworden nicht mit so viel Statischen Sachen zu arbeiten, sondern mehr mit dynamischen Ellenenten.
Das entspricht auch mehr den OOP Richtlinien.

Wie hoch ist denn eigentlich der speicherverbrach vor und nach dem um schalten gib da mal genaue Zahlen. Oder besser zu wieviel Prozent ist der Heap vor dem umschalten gefüllt.

Hier mal ein einfache Beispiel wo du beobachten kannst wie sich der GC verhält.
Es macht auch sinn es mal unter verschiedenen Android Versionen laufen zu lassen. Denn das verhalten des GC ist da sehr unterschiedlich.
Beim Speichern werden ca. 4 MB auf dem Heap gespeichert. Was nach einer bestimmten Menge ohne löschen zu einen OutOfMemory füht.
Bei Android 8 frirt die App erstmal ein der GC versucht ohne ein zutuen des Users den Speicher zu bereinigen schafft es nicht bricht dann aber doch ab.
Bei Android 5 wird zB. gleich beendet.
Du sieht das also auch die Android Version eine Rolle spielt.

public class MainActivity extends AppCompatActivity implements View.OnClickListener {
    private String[][] as;
    private int index = 0;
    private Runtime runtime = Runtime.getRuntime();
    private TextView tv;




    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        tv = findViewById(R.id.tv);


        findViewById(R.id.alloc).setOnClickListener(this);
        findViewById(R.id.showString).setOnClickListener(this);
        findViewById(R.id.loeschen).setOnClickListener(this);
        findViewById(R.id.loeschenGC).setOnClickListener(this);
        findViewById(R.id.loeschenRGC).setOnClickListener(this);


        as = new String[1000][];
        showMemory();
    }


    @Override
    public void onClick(View v) {
       switch (v.getId()){
           case R.id.alloc:
               if (as == null) {
                   as = as = new String[1000][];
                   index=0;
               }
               String[] star = new String[100_000];
               for (int i = 0; i < 100_000; i++)
                   star[i] = new String(" ");
               as[index++] = star;
               showMemory();
               break;


           case R.id.showString:
               showMemory();
               break;


           case R.id.loeschen:
               as = null;
               showMemory();
               break;


           case R.id.loeschenGC:
               as = null;
               System.gc();
               showMemory();
               break;


           case R.id.loeschenRGC:
               as = null;
               runtime.gc();
               showMemory();
               break;
       }
    }


    private void showMemory() {
        long max = runtime.maxMemory()/1024;
        long total = runtime.totalMemory()/1024;
        long free = runtime.freeMemory()/1024;
        long consumed = (runtime.totalMemory() - runtime.freeMemory())/1024;
        tv.setText("\n\nMax Memory (KB): " + Long.toString(max) +
                "\nTotal Memory (KB): " + Long.toString(total) +
                "\nFree Memory (KB): " + Long.toString(free) +
                "\n\nMemory consumed (KB): " + Long.toString(consumed)+
                "\n\n Index: " + Long.toString(index)
        );
    }
}

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity"
    android:orientation="vertical" >


    <Button
        android:id="@+id/alloc"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Alloc Speicher" />
    <Button
        android:id="@+id/showString"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Zeige  Speicher" />
    <Button
        android:id="@+id/loeschen"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Speicher Löschen" />
    <Button
        android:id="@+id/loeschenGC"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Speicher Löschen mit System GC" />
    <Button
        android:id="@+id/loeschenRGC"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Speicher Löschen mit Runtime GC" />
    <TextView
        android:id="@+id/tv"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:textAppearance="?android:attr/textAppearanceSmall"
        android:text="Total Memory: "
        android:layout_marginTop="40dp" />
</LinearLayout>

Grosse globale (Klassen Variablen) Arrays sind immer etwas schwierig zu handeln sollte man nicht machen.
Siehst ja was dabei rauskommt.
Dabei spielt es auch keine Rolle ob du die static, final oder nicht machst.

Hallo
Erstmal eins zum Verständnis das was du als Liste bezeichnest ist keine dynamische Liste sondern ein Array. Was durch das new String[] ihre Grösse bekommt.
Danach auch nicht mehr änderbar ist.
Variablen mit [] sind statische Arrays. Keine Listen die dynamisch erweiterbar sind.

Eine List ist so etwas hier
List<String> mList = new ArrayList<String>();
Zugrif mit get(), set(), add()

In deinem Adapter wird bestimmt das Array in eine Liste übertragen denn der Adapter arbeitet mit Linsten nicht mit Arrays.
https://developer.android.com/…droid/widget/ArrayAdapter

Eine Liste (dynamisch) hat immer Spitze Kammern <>

Zitat

Hier habe ich eine globale Variable String [] taskTitles; angelegt

meiner Meinung nach gibst du mit "taskTitlesAssigned = null;" das Statische Array nicht frei.

ein im Quellcode erstelltes Member Klassen Array wird bestimmt nicht freigegeben.
Außer du erstellst sie in einem Block ( Methode) da könnte das schon gehen.
Mit erstellen meine ich nicht zuweisen sonder Definieren.

Beendest du wirklich alle threads beim beenden der activity system.exit(0)

80 image button da wundert es mich nicht.
Mit dem Speicher.

Frage wie groß sind denn die Image Dateien?

Zu der Listeview wieso löscht du nicht den Inhalt der Liste und speicherst neue Werte in der Liste. Auf die dann der Adapter wider zugreift.

Zum Schluss mal eine grundlegende Frage

Ich hoffe du arbeitest mit Android Studio und nicht mit Eclipse. Was schon lange nicht mehr richtig unterstützt wird.

Die Frage stellt ich weil du bei C bestimmt eclipse benutzt.

Hallo

Zitat

bzw. würde das erst nach tausenden Schaltversuchen machen. Man sieht bei dieser kleinen Demo aber deutlich im Emulator/Profiler, das sie Speicher belegt und nicht freigibt.

Das ich kann so nicht Bestätigen. Ich habe auch mal so weine einfache App mit zwei Activity und Button gemacht und im Profiler den Ram verbrauch beobachtet. Am Anfang nach zwei drei Wechsel ging er leicht hoch pegelt sich aber ein, und von da ab wird Speicher verbraucht und wieder freigegeben. Klar das freigeben ist etwas verzögert. Ist aber normal.
Wenn das bei dir nicht so ist, stimmt irgendwas mit deinen Handy oder System nicht.
Es kann nicht sein das sich der Speicher bei so einer einfachen App ständig zu nimmt und nicht wieder freigegen wird.

Zitat

Ich komme eigentlich aus der C-Ecke und bin es da gewohnt, das man das, was man reserviert, auch selbst wieder freigibt. Und es wäre schön gewesen, wenns bei Android auch so eine Möglichkeit gegeben hätte.

Ist es ja auch in einem gewissen Rahmen. Du kannst es zwar nicht selber machen wie in C aber du kannst dem GC sagen das du das Objekt die Instanz nicht mehr brauchst und er es Freigeben kann.

Lösche einfach die Instanz wenn du sie nicht mehr brauchst.
„Null“ bei Java ist gleich wie bei C.

Wenn du also eine Variable auf null setzt wird sie vom GC erkannt und der reservierte Speicher wird freigegeben. Natürlich nicht gleich wie bei C, sondern wenn der GC Zeit hat oder wen der Speicher knapp wird sonnst tut er nichts.

Also wie ich schon sagte solltest du in der onDestry() Methode die ja beim beenden durchlaufen wird die wichtigsten Variablen wieder auf „null“ setzen damit der GC weiß das sie nicht mehr gebraucht werden.

Auch sagte ich dir das du nach dem "finish()" auch ein "System.exit()" machen sollst. Denn damit sollte der GS nach nicht benutzten Instanzen suchen und die Activity wirklich richtig beenden.
Das kannst du auch im Emulator beobachten. Das nach einem System.exit(0) die Activity komplett neu aufgebaut wird. Der Wechsel von der einen Activity zu anderen dauert dann etwas länger. Auch werden damit noch eventuell laufende Threads beendet.

finish();
System.exit(0);

// benutzen Speicher wieder freigeben beim Beenden.
	List<String> farben;
    protected void onCreate(Bundle savedInstanceState) {
        ....                
                farben = new ArrayList<String>();
                farben.add("rot");
                farben.add("blau");


        }
    protected void onDestroy() {
        super.onDestroy();
        farben=null;
    }

Zitat

Also werde ich wohl jetzt deinen Rat befolgen und mich in das Thema Fragmente einlesen, alles umschreiben um dann am Ende wieder festzustellen, das Fragmente leider keine Buttons unterstützen oder nur in chinesischer Sprache funktioniern..

Ob dir das hilft mag ich zu bezweifeln, wenn du deine Speicherverwaltung nicht in den Griff bekommst.
Und solche Sachen wie Button nur in Chinesisch zeigt mir das du immer noch an den Falschen stellen suchst.

Zitat

Ich dachte: Kein Problem, fängst du einfach das onBackPressed ab ..... Pustekuchen. Geht bei Activities nicht ( keine Ahnung, warum nicht ).

Stimmt auch nicht.

In eine Activity läst sich der OnBack Button abfangen. Wie hast du das den bis jetzt gemacht?

In eine Activity gibt es weiterhin die Methode „onBackPressed“
https://developer.android.com/…tivity.html#onBackPressed()

Das hat mit der AppBar nichts zu tun.
du willst doch die Hardware ( neu Software) Taste benutzen oder?

Besonders bei deinem Versuch mit dem LayoutSwitcher musst du extrem darauf aufpassen wo du dich gerade befindest, um auch richtig und sinnvoll zu Reagieren.
Damit meine ich , du musst immer wissen welches Layout gerade activ ist und welche IDs (Button,Texte …) gerade im Layout vorhanden (geladen) sind. Notfalls musst du auch ständig immer wieder das findviewbyId machen, und prüfen ob eventuell Nullpointer entstanden sind. Das ist meiner Meinung sehr aufwendig und Fehler trächtig.

Diesen Vorschlag wird dir bestimmt kein erfahrener Programmierer geben.

Zu der Frage viel RAM das Handy hat. Gab es keine Antwort. Ich finde das schon etwas wichtig. Denn die maximale Standart Heap Größe ist vom verbauten RAM abhängig. 1 GB RAM ca 128 MB Heap
Bei 2gb schon 256 MB Heap als Standart.
Und wenn die erreicht ist sollte der GC spätestens aktiv werden.
Und jenachdem was du machst also wofür du Speicher verbrauchst. Ist das etwas entscheidet. Bei vielen großen Bildern zb. Grossen Speicher intensiven Listen....

Welche Meldung bekommst du denn überhaupt wenn das Handy hängt?
Wäre auch nicht schlecht zu wissen.

Benutzt du etwa auch thread die nicht richtig beendet werden. Denn wenn du keine Meldung über Out of Memory bekommst. Scheint mir das mehr in diese Richtung zu gehen.

Zitat

Das liegt aber nicht direkt am Editor, denn das Gleiche passiert auch mit einer einfachen Einstellungs-Activity mit ein paar Edit Feldern und Buttons

Wenn dem wirklich so ist würde mich diese activty mal interessieren

Noch ein Tipp denn ich auch schon erwähnt habe ist die Methode.
onDestry die beim beenden der activity aufgerufen wird. Setze doch da mal ein Log und schaue in der logcat ob sie aufgerufen wird. Wenn ja wird sie beendet. Ob dabei alle Instanzen bei deiner richtigen App gelöscht werden ist damit aber noch nicht bewiesen.
Nur das wirklich die activity beendet ist und sie beim Aufruf wieder erstellt wird. Was der Standart ist bein wegsel der activity mit finish.

https://developer.android.com/…vities/activity-lifecycle

Hallo das es mit den ständigen ContentView nicht geht hätte ich dir auch sagen können war mir auch klar. Hatte gestern keine Zeit mehr.

Wenn du dir mal klar machst was in der Methode alles gemacht wird, ist das auch logisch. Es wird immer wieder dein Layout eingelesen und die Views Objekte instanziiert. Also das layout immer wider neu aufgebaut. Beim beenden der Activity werden die Instanzen ungültig und der GC kann sie freigeben.
Da du die activity nicht beendest werden ständig von setcontentview erstellten Objekte nicht zurückgeben.

Wenn du ständig das Layout ändern willst solltest du das selber machen, und nicht setcontentview überlassen. Mit Hilfe des Inflater und natürlich die benutzen Instanzen auch wieder freigeben.
Das ist auch der Grund warum das ändern des Layouts in der Activity so Fehler anfällig ist und davon angeraten wird. Auch ich habe dir abgeraten, wenn du so etwas willst braucht sind Fragmente die besser Wahl. Dafür wurden sie auch geschaffen.

Im übrigen ist es mir noch nicht passiert das so eine einfache App wie in deinem ersten Post das Handy lahm legt.

Auf die Punkte die ich angesprochen habe geht du gar nicht ein.sondern suchst den Fehler etwas an der falschen Stelle.
Die Möglichkeit das der Speicher nicht freigeben werden kann weil Objekte Instanzen nicht ungültig werden. Aber trotzdem neue Objekte herstellt werden gehst du auch nicht ein.

Zu diesen beiden Klasse im Post 1
Frage ich mich warum du in der Activity A den Button der Activty B suchst.
Benutzen tust du ihn nicht.

Den brauchst du gar nicht , den du benutzt bestimmt das OnClick im XML um einen Bezug zum Clicklistner zu haben.
In der anderen Klasse Activty B suchst du den Button A .

Das mit den findviewbyi und anschließenden setzen eines klicklistner braucht man bei Button wo das onClick im XML nicht benutzt wird.
Ich persönlich Finde das sowieso überholt den bei Fragmente geht das auch nicht mehr.

Warnlicht ist der GC zu langsam um die Instanz des Button oder sogar der activity löschen und du erstellst somit auch wieder eine neue Instant des Button.

Eigentlich solltest du da einen Nullpointer bekommen.
Merkst das aber nicht da du die variable gar nicht benutzt.
Wenn du es mir nicht glaubst teste es und setze den Text des Buttons.

Da ich deine Layouts nicht kenne gehe ich mal davon aus das der Button buttonStart_B in dem Layout activityB ist.
Wenn dem so ist was willst du damit in der activity A?

Lasse das FindVievById in den Klasse weg und schaue mal ob dir die Handy noch abstürzt.

Der Kontext ist zb das tihs der activity. Das du in der Klasse brauchst um auf die resoursen der activity zu zugreifen. Beim Instanzen der Klasse mit New solltest du den context mit übergeben.

In der Klasse
Context context;
public getZone(Context cx) {
context = cx;}

werte = context . getResources().getStringArray(R.array.routen_Gardasee);

In der activity

getZone get = new getZone( this);

https://developer.android.com/…e/android/content/Context

Zeige mal wie du das im Java für Desktop machst.

Android ist ein framework

Zitat

Es wäre schön, wenn man einer einzigen Activity mehrere Layouts zuweisen und hin und herschalten könnte, aber genau davon raten viele Tutorials ab und empfehlen lieber mehrere Activities.

Das layout tauschen ist wirklich keine gute Idee und auch Fehler anfällig. Das würde ich Fragmente benutzen.

Zitat

Nur: Irgendwas muss ich dabei falsch machen.

Ja bestimmt nur kann ich da so aus der fernen nichts dazu sagen.

Bestimmt benutzt du Speicher den du nicht wieder zurück gibst.
Beendest schließt vielleicht offne Dateien nicht, schließt auch keine Streams ....
Vielleicht machst du auch viel mit static oder du benutzt sehr große Bilder Icons ….

Ohne Code kann man da wenig sagen.

Beende mal alle Instanzen und Objekte in der onDestry() Methode. Die wird beim zerstören der Activity aufgerufen.

Wie viel RAM hat denn dein Handy?
Welche Android Version?
Ist dieses Verhalten auch bei anderen Apps oder nur bei deiner APP?

PS auch ein Grund könnte sein das du threads benutzt und dise nicht beendet. Die dann so zusagen ewig laufen.

Hallo eigentlich sollte das der GC selbständig im Hintergrund erledigen.

Wahrscheinlich schaltest du zu schnell hin und her und der GC ist nicht so schnell.

Um die activity sicher zu beenden füge noch system.exit(0) nach dem finish hinzu.

Somit sollte der GC den Speicher freigeben. Was aber immer etwas dauern kann. Denn auch das freigeben von Speicher kostet cpu Zeit und damit Akku.
Und genau da setzen die moderneren System an und versuchen einzusparen.

Einen Wechsel von einer activity zur anderen aller 2 sek macht der User eigendlich nicht.

Hallo so wie du das machst geht das nicht.

Die Klasse braucht nicht von Activity zu erben. Das bringt dir auch nichts.
Das was du da erbst ist auch die falsche Instanz.

Du musst den Kontext der Actiyity an die Klasse übergeben.
Über diesen Kontext kannst du in der Klasse auf Objekte der Activity zu greifen.
Übergebe den Kontext im Konstruktor an die Klasse.

Erben brauch die Klasse nicht.

Grundlagen OOP . Auslagern in externe Klassen.