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

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.

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.