Dlaczego muszę wyczyścić pamięć podręczną Dalvik?


46

Podczas aktualizacji niestandardowej pamięci ROM zawsze jest dostępna instrukcja czyszczenia pamięci podręcznej Dalvik . Nie widzę powodu, dla którego jest to koniecznie.

Obserwując logcat podczas uruchamiania systemu, wyraźnie widzę, że jeśli aplikacja ulegnie zmianie, jej dexplik zostanie unieważniony, a następnie ponownie wygenerowany. Jednak wciąż, gdy wspominam o tym wszędzie, spotykam się z ciszą. Jakby nawet niektórzy programiści ROM nie wiedzieli o tym i robią to tylko dlatego, że wszyscy inni to robią.

Więc pytania:

  • Czy była wersja Androida, w której pliki Dalvik nie zostały unieważnione podczas rozruchu?
  • Czy jest jakaś korzyść z robienia tego samemu, zamiast pozwolić systemowi wykonać pracę, którą powinien wykonać?

Idealna odpowiedź zawierałaby odniesienia do odpowiedniego kodu, więc miałbym odniesienie następnym razem, gdy to się pojawi.

Odpowiedzi:


43

Aby odpowiedzieć na pytania:

  • Nie znam żadnej wersji Androida, w której Dalvik nie został unieważniony przy starcie. Może początkowa wersja 1.0 miała to, naprawdę nie wiem, przeszło przez Eclair, Froyo, Gingerbread, Ice Cream Sandwich. Musisz zajrzeć do drzewa źródłowego i ponownie ustawić go w CupCake lub Doughnut (odpowiednio 1,5 i 1,6)

  • Szczegółowy powód :)

Powodem, dla którego należy użyć czyszczenia pamięci podręcznej, jest to, że wszystkie apki, w tym apki systemowe, mają dołączony plik dex , kiedy ROM jest uruchamiany po raz pierwszy, Dalvik dla Androida przegląda wszystkie apki i rozpakowuje plik dex z niego i umieść go w pamięci podręcznej, /data/dalvik-cacheprzyspieszając w ten sposób wykonanie samej aplikacji.

Większość ROM-ów ma apki odexdowane , pamięć podręczna jest pakowana w sam apk jako plik zewnętrzny.

Wiele niestandardowych moderów ROM miałoby te pliki deodex 'd, co oznacza, że ​​plik dex jest zastępowany i ponownie pakowany , aby ułatwić tworzenie motywów / modyfikację pliku APK.

Gdy flashujesz niestandardową pamięć ROM i nie wyczyścisz pamięci podręcznej, do apk nowszych niestandardowych pamięci ROM zostanie dołączony inny plik dex , a gdy Dalvik przejdzie przez nie, zobaczy istniejący buforowany plik dex znaleziony w katalogu, i pomija go, a następnie po uruchomieniu aplikacji masz gwarancję siły zamknięcia lub ANR (brak odpowiedzi aplikacji).

Nie tracisz danych jako takich, jeśli wybierzesz ClockWorkMod Recovery i wyczyścisz dane , to tak, wszystkie ustawienia dotyczące aplikacji zostaną wyczyszczone - spójrz /data/app.

Więc możesz wyczyścić pamięć podręczną, ale nie wyczyść danych , co zostało zrobione skutecznie, jest umieszczane w nowszych aplikacjach, w których zachowano ustawienia. Był to dość powszechny scenariusz z nocnymi lampkami CyanogenMod, w których miga niestabilna / testowa kompilacja ROM, a ustawienia zostają zachowane wraz z czyszczeniem pamięci podręcznej. Przebieg będzie się różnić w zależności od aplikacji pobranych z rynku (ustawienia prawdopodobnie zmieniłyby się w zależności od wersji).

Aby uzyskać najlepsze wyniki, rozsądnie byłoby wykonać czyszczenie danych i czyszczenie pamięci podręcznej, aby zapewnić integralność i brak błędów programu w samej aplikacji.

Tak, to znaczy, że czas rozruchu byłby wolniejszy, ale jego początkowy moment jednorazowy. Potem będzie szybciej się uruchamiał. Naprawdę w skrócie, wyraźne wyczyszczenie samej pamięci podręcznej za pomocą CWM faktycznie przyspiesza ją i zapewnia, że ​​nie pozostały żadne pozostałości z poprzedniej wersji, które mogłyby zostać zmiażdżone (Teraz na tym etapie, zdaję sobie sprawę z twojego pytania, więc uczciwie, tak naprawdę widział, że Android nie wykonuje unieważnienia samej pamięci podręcznej podczas rozruchu podczas flashowania nowej pamięci ROM ..)

Poważnie używaj źródła Luke ! :RE

frameworks/base/core/java/com/android/internal/os/ZygoteInit.javato kod rozruchowy dla każdego środowiska wykonawczego apk. Współdziała z natywnym kodem C znajdującym się w dalvikdrzewie katalogów, które zawiera określone instrukcje mikroukładu, aby zinterpretować kod bajtowy w pakiecie apk do zestawu instrukcji natywnego procesora. ARMv6 to właściwie zhakowana wersja ARMv5 (który był oryginalnym chipsetem w starszych wersjach Androida przed Eclair), więc nie zobaczysz ARMv6 w źródle AOSP z Google. CyanogenMod będzie miał ARMv6 w swoim źródle.


Na potrzeby tej dyskusji załóżmy, że mówimy o oficjalnej wersji CM7. Zacznę od stwierdzenia, że ​​nigdy nie wycierałem mojej pamięci podręcznej Dalvik i nigdy nie doświadczyłem problemów, które można by przez to rozwiązać. Ponieważ nie jest odexedowany, nie ma możliwości, aby obecnych było wiele plików (o) dex, a zatem przy starcie stary plik jest zastępowany przez nowo wygenerowany. Aha, a jeśli to naprawdę wielka sprawa, dlaczego programiści nie dodają tego do skryptu aktualizacji? Sprawdzę źródło, dzięki.
RR

1
Możesz faktycznie wprost to umieścić w skrypcie aktualizującym, ale to może wkurzyć innych podczas flashowania, ponieważ „O cholera, straciłem moje ustawienia / dane”, a CM prawdopodobnie nie chciał zostać poparzony przez płomienne pytania / odpowiedzi jak w „ Dlaczego wyczyściłeś moją pamięć podręczną podczas flashowania nowej wersji CM? ” - może to odpowiedzialność CM, więc dała tę opcję użytkownikowi końcowemu? I umieszczając je z powrotem na nich, aby jeśli błysnęły bez wycierania, i zaskomlały na forach: „Hej, moja aplikacja się zawiesza”, CM może się odwrócić i powiedzieć „Czy wyczyściłeś?”
t0mm13b

Nie miałem na myśli data/dataale data\dalvik-cache. Być może tylko te systemowe.
RR

1
Standardowe ROMy AOSP są odexowane, CM zmodyfikował system kompilacji, aby używał deodex .... tylko mówiąc;)
t0mm13b

2
Dzięki za szczegółową odpowiedź t0mm13b. Po prostu jestem pewien ... Wydaje się, że prosta odpowiedź na zadane pytanie brzmi: „Nie robisz. Domyślnie jest usuwany podczas uruchamiania”. Poprawny?
GollyJer
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.