Warum muss ich den Dalvik-Cache löschen?

Wenn ich ein benutzerdefiniertes ROM aktualisiere, gibt es immer eine Anweisung, den Dalvik-Cache zu löschen . Ich sehe keinen Grund, warum dies unbedingt sein muss.

Wenn ich das Logcat beobachte, während das System hochfährt, kann ich deutlich sehen, dass, wenn eine App geändert wird, ihre dexDatei ungültig gemacht und dann neu generiert wird. Und doch, wenn ich das irgendwo erwähne, stoße ich auf Schweigen. Als ob nicht einmal einige ROM-Entwickler sich dessen bewusst wären und sie dies nur tun, weil alle anderen es tun.

Also die Fragen:

  • Gab es eine Android-Version, bei der Dalvik-Dateien während des Bootens nicht ungültig gemacht wurden?
  • Gibt es einen Vorteil, dies selbst zu tun, anstatt das System die Arbeit machen zu lassen, die es tun soll?

Eine ideale Antwort würde Verweise auf den relevanten Code enthalten, sodass ich beim nächsten Mal einen Verweis haben würde.

Antworten (1)

Um Ihre Fragen zu beantworten:

  • Mir ist keine Android-Version bekannt, bei der Dalvik beim Booten nicht ungültig gemacht wurde. Vielleicht hatte die ursprüngliche Version 1.0 das, ich weiß es wirklich nicht, durch Eclair, Froyo, Gingerbread, Ice Cream Sandwich gegangen. Sie müssen in den Quellbaum schauen und ihn auf CupCake oder Donut (1.5 bzw. 1.6) zurücksetzen.

  • Der genaue Grund :)

Der Grund, warum der Wipe Cache verwendet werden muss, ist, dass alle APKs, einschließlich System-APKs, eine dex -Datei angehängt haben, wenn das ROM zum ersten Mal hochgefahren wird, geht Dalvik von Android jede einzelne dieser APKs durch und extrahiert sie die dex-Datei daraus und legen Sie sie im Cache ab, /data/dalvik-cachewodurch die Ausführung der App selbst beschleunigt wird.

Die meisten ROMs haben apks, die odex -ed sind, der Cache ist in der apk selbst als externe Datei gebündelt.

Viele benutzerdefinierte ROM-Modder hätten diese apks deodex 'd, was bedeutet, dass die dex-Datei ersetzt und neu verpackt wird, um das Thema/Ändern einer apk zu vereinfachen.

Wenn Sie ein benutzerdefiniertes ROM flashen und den Cache nicht löschen, haben die neueren benutzerdefinierten ROM-APKs eine andere Dex -Datei angehängt, und wenn der Dalvik sie durchläuft, sieht er die vorhandene zwischengespeicherte Dex-Datei, die im Verzeichnis gefunden wurde, und Wenn Sie es überspringen, wird Ihnen beim Ausführen der App garantiert ein Force Close oder ANR (Application Not Responding) angezeigt.

Sie verlieren per se keine Daten, wenn Sie ClockWorkMod Recovery verwenden und Wipe Data ausgewählt ist, dann werden ja alle Einstellungen in Bezug auf die Apps sauber gelöscht - schauen Sie in /data/app.

So kann man Cache Wipe aber nicht Wipe Data , was effektiv gemacht wird, wird in den neueren apks an Ort und Stelle gesteckt, in denen es die Einstellungen beibehalten hat. Dies war ein recht häufiges Szenario bei CyanogenMod-Nightlies, bei denen ein instabiler/testender ROM-Build geflasht wird und die Einstellungen beim Cache-Wipe beibehalten werden. Die Laufleistung hängt davon ab, welche Apps vom Markt heruntergeladen wurden (die Einstellungen hätten sich wahrscheinlich durch einen Versionsstoß geändert).

Um die besten Ergebnisse zu erzielen, ist es ratsam, sowohl Daten als auch Cache zu löschen, um die Integrität und keine Programmfehler in der App selbst sicherzustellen.

Ja, das würde bedeuten, dass die Startzeit langsamer wäre, aber der erste einmalige Moment. Danach würde es schneller booten. Kurz gesagt, das explizite Löschen des Caches selbst über CWM hilft tatsächlich dabei, ihn zu beschleunigen und sicherzustellen, dass keine Rückstände der vorherigen Version vorhanden sind, die sich einmischen könnten (jetzt verstehe ich Ihre Frage ehrlich gesagt nicht wirklich gesehen, dass Android beim Booten beim Flashen eines neuen ROMs die Invalidierung des Caches selbst nicht durchführt..)

Verwenden Sie die Quelle Luke ernsthaft! :D

frameworks/base/core/java/com/android/internal/os/ZygoteInit.javaist der Startcode für jede APK-Laufzeit. Es interagiert mit dem nativen C-Code im dalvikVerzeichnisbaum, der spezifische Chipsatzanweisungen enthält, um den Bytecode innerhalb des apk-zu-nativen CPU-Befehlssatzes zu interpretieren. ARMv6 ist so ziemlich eine gehackte Version von ARMv5 (das war der ursprüngliche Chipsatz in den älteren Android-Versionen vor Eclair), sodass Sie ARMv6 nicht in der AOSP-Quelle von Google sehen werden. CyanogenMod wird dieses ARMv6 in seiner Quelle haben.

Nehmen wir für diese Diskussion an, dass wir über eine offizielle CM7-Version sprechen. Lassen Sie mich zunächst sagen, dass ich niemals meinen Dalvik-Cache gelöscht habe und niemals Probleme hatte, die dadurch gelöst würden. Da es nicht odexiert ist, können auf keinen Fall mehrere (o)dex-Dateien vorhanden sein, und daher wird beim Booten die alte Datei durch eine neu generierte ersetzt. Oh, und wenn es eine wirklich große Sache ist, warum fügen die Entwickler das nicht in das Updater-Skript ein? Ich werde die Quelle überprüfen, danke.
Das kann man eigentlich explizit in das Updater-Skript packen, aber das kann andere beim Flashen verärgern, weil "Oh Mist, ich habe meine Einstellungen/Daten verloren" und CM wollte sich wahrscheinlich nicht von den Fragen/Antworten der Flamme verbrennen lassen wie in " Warum haben Sie meinen Cache gelöscht, als Sie eine neue Version von CM geflasht haben?" - Vielleicht liegt es an der Verantwortung von CM, also hat er diese Option dem Endbenutzer gegeben? Und es wieder auf sie zu setzen, damit CM sich umdrehen und sagen kann, wenn sie ohne Wipe geflasht haben und in den Foren a lá "Hey, meine App stürzt ab" jammern und sagen können: "Hast du gewischt?"
Ich meinte nicht data/dataaber data\dalvik-cache. Möglicherweise nur die System.
Standard-AOSP-ROMs sind odexiert, CM hat das Build-System so modifiziert, dass es Deodex verwendet ... nur um zu sagen;)
Letzter abschließender Kommentar: Einige ROM-Modder würden ihren Code entweder auf AOSP-Vanilla, CAF oder CM basieren. Wenn Sie also beispielsweise von CM zu CAF wechseln, löschen Sie aufgrund von Unterschieden explizit die Daten/den Cache, ebenso für das Gehen von AOSP zu CM. Hier kommt der gesunde Menschenverstand ins Spiel. Aber Sie scheinen sich nur auf CM zu konzentrieren, von einer Nacht zur nächsten oder von Stable zu Stable zu gehen, dann ja, keine vernachlässigbaren Unterschiede, abgesehen von ROM-Signaturschlüsseln usw. Ebenso, wenn Sie auf GB CM72 sind und zu gehen ICS CM9, dann wäre es ja ratsam, dasselbe zu tun!
Ich konzentriere mich nur auf CM, weil ich nur CM-Threads in Foren besuche, also sehe ich nur, was sie sagen. Für den Wechsel zwischen den wichtigsten Zweigen kann ich die Notwendigkeit verstehen, sie zu löschen (Unterschiede in der VM vielleicht?) Oder zwischen den Betriebssystemversionen (2.3 bis 4.0), aber ich mache es nie für etwas anderes, und mein Telefon funktioniert gut. Es sieht also so aus, als ob es für den ursprünglichen Fall (Aktualisierung auf Never-Rom-Version) wirklich nur darum geht, etwas als Versicherung zu haben, wenn sich Benutzer beschweren.
Hinweis: Dieses gedankenlose Tun, weil alle anderen es tun, ist unter den Rom-Köchen von Modaco (den Jungs, die mit Winzip arbeiten) sehr verbreitet.
Danke für die ausführliche Antwort t0mm13b. Nur damit es klar ist ... Es scheint, dass die einfache Antwort auf die gestellte Frage lautet: "Sie tun es nicht. Es wird standardmäßig beim Booten gelöscht." Richtig?
Gilt diese Antwort immer noch für Android 7 oder höher? Weil es scheint, dass Dalvik-Caches beim Neustart nicht generiert werden, sobald sie gelöscht wurden. Was ist los?
Warum muss ich den Dalvik-Cache löschen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v